The Objective-C Language
Subject:   IMHO the right way to do setter selector definitions
Date:   2001-07-04 20:00:55
From:   bigboytoddy
Response to: Returned Data types of methods

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.

- 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

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

Best wishes, I do hope this helps.


1 to 1 of 1
  1. Calling [super init] within your own initXXX methods
    2001-07-04 20:13:20  bigboytoddy [View]

1 to 1 of 1