Article:		The Objective-C Language
Subject:		Returned Data types of methods
Date:		2001-07-04 19:49:13
From:		bigboytoddy
Response to: Definitions of Interface/Implementation, it is in error to say ObjC defines these in seperate files.
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

Showing messages 1 through 2 of 2.

• 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