|
Hi, this is not a correction, more of an opinion...
In the past, and currently the setIVar has always been assumed, and for reasons doing with Interface Builder, the method say for iVars defined in the @interface as
@interface YourClass : NSObject
{
id someVar;
id someOtherVar;
}
// no need to define setters in the interface,
// by default they are already called if you
// define them in the implementation, the runtime
// (folks, you should read the runtime stuff if
// you have not already, those low level C functions
// will really clear things up for you about how
// things are done, management of selectors in
// the class structure, creating new methods on
// the fly if you wanted, say for behavioral
// based systems, adding interfaces to live
// classes, all kinds of cool stuff) will call
// the automagically, maybe that has been removed... but back to the real issue of naming.
@
@implementation
- setSomeVar
{ // do something useful, gets called upon initing
// allowing setup of vars... I think this still
// exists, yet I could be so old and decrepid
// NeXT/Apple may have taken this out
}
- setSomeOtherVar
{ // same as above, gets called automagically
}
@end
Now I hope Apple has stopped this, for obvious
reasons, it was undocumented and also really
messed things up when you wrote code, and didn't
know the side effects.
Basically it boils down to this, and is related
to the ramblings above. In Smalltalk, there
is a practice of naming (and it is good) for
getters and setters, 1/2 of which is follwed
for them most part in the ObjC community. I
highly recommend folks do this also...
The colon is part of the naming convention, yet
is really useful as a 'setter' word, indicating
something is being set... It is pretty obvious
when reading code that something is an iVar, without
explicitely telling them in the name, we all read
enough of it eventually to know with naming things
right, a method named
- center // would return the center of an object
- center: newCenter // would set same
That is it, instead of this stuff like
- getCenter // which I still see in code reviews
- setCenter: newCenter // which is redundant
That is it, tangential stuff aside, this is the
whole of my point, the ':' is part of the selector
definition, and unfortunately we often only use
it to visually seperate the selector from the
variables, in reality it is PART of the selector
itself and has value, especially in such obvious
settings.
Best wishes, I do hope this helps.
\t
|
It was pointed out that your method for init (custom derivations and default initializer) would look like this for the class Circle...
@interface Circle : SomeOtherClass
{
double radius; // should be NSNumber IMHO
}
- initWithRadius: (double)r;
@end
@implementation Circle
- initWithRadius: (double)r
{
radius = r;
}
@end
In reality, this could and likely will be troublesome. It assumes there is no additional initialization done by the parent class... Bad assumption, really bad.
The correct way to define a default initializer method is more like
- init
{
return ( [self initWithX: defaultValueForX ] );
}
// This is the designated init method for this class
- initWithX: valueHolderForX
{
[super init]; // us the default initializer for the super class, init can be assumed, yet it would help to know your parent implementation since indeed you are inheriting functionality from it, makes sense to know it. There may be specific default initializers that are more useful and appropriate for your use.
// set your iVars here
x = valueHolderForX;
[ ... maybe private iVars are set here ... ]
}
Hope this helps.
\t