Article:  |
The Objective-C Language | |
| Subject: | Definitions of Interface/Implementation, it is in error to say ObjC defines these in seperate files. | |
| Date: | 2001-07-04 19:36:15 | |
| From: | bigboytoddy | |
|
Well, just being the nitpick that I am, here is another error...
|
||
Showing messages 1 through 5 of 5.
-
Definitions of Interface/Implementation, it is in error to say ObjC defines these in seperate files.
2001-07-04 19:42:04 bigboytoddy [View]
-
Definitions of Interface/Implementation, it is in error to say ObjC defines these in seperate files.
2001-07-04 19:45:55 bigboytoddy [View]
"Every class implementation must import its own interface file."
This statement is just flat out wrong. You don't have to have them in seperate files. Every class implementation must have a cooresponding class interface, prior to the definition of the methods.
Again, they may be contained in the same file. I'll stop now, before I have to repeat myself again ;'P Read previous jibberish by me to see details on this issue.
-
Returned Data types of methods
2001-07-04 19:49:13 bigboytoddy [View]
In fact, I believe that the id reference is always 'self', unless it is explicitely changed, say as returning a substitute class or even having it poseAs?, so if this true (I'm having a brain fart right now) it would conclude that in class methods '+' that would be indeed the class itself, and in instance methods '-', self would be the instance of course. I stand corrected if I'm wrong, wouldn't that explain it clearer? LOL
\t
-
IMHO the right way to do setter selector definitions
2001-07-04 20:00:55 bigboytoddy [View]
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
-
Calling [super init] within your own initXXX methods
2001-07-04 20:13:20 bigboytoddy [View]
Hello again.
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
If we are using a OO hybrid-language, and OO supporting libraries, it makes sense to use OO then in our code.
The following
double radius;
double xLocation;
double yLocation;
NSColor *color;
Should be replaced with
NSNumber *radius;
NSNumber *xLoc;
NSNumber *yLoc;
which allows much more consistant usage of the language and the functionality of the method selectors in the frameworks and work of other developers (MiscKit for OSX and such).
This again is one of the PROBLEMS of ObjC, that folks coming over from C continue to use the C definitions, when in fact there is optimized and highly effective means to use objects throughout the language. Apple has done a fairly good job in providing most structures and primative data types with higher level object wrappers. Please, folks, including the author, use them. You will thank yourself and Apple later when the finally get to the point of OO'ing ObjC where it is more consistant.
\t