On Mar 8, 2015, at 20:45 , Patrick J. Collins <[email protected]> wrote: > > Sorry-- where was I using getters? You mean setters? > > self.ks = ks?
Apologies, I meant to say accessors, and yes I was referring to that line and the one after it. > I tend to use setters because sometimes I'd like to have a side-effect of > the setting.. like formatting the value in some way, and have that built > into the process of setting the property. The general problem is that during the ‘init…’ method, the object is not necessarily fully “constructed”. Indeed, almost by definition it can’t be, at least at the beginning of the method. Therefore, other methods might not see a complete or consistent state, so their behavior might be unpredictable. Unfortunately, again in general, it’s not good enough to reason about the actual behavior of methods of the class that are invoked in the initializer, because if the class gets subclassed, then the actual methods executed might be overrides in the subclass, and the subclass certainly hasn’t had a chance to initialize itself. This mightn’t go badly for you right away, but might blow up in your face at some future time when you add behavior. The general recommendation is, if you know you are just setting a value, to use the ivar directly. If there is behavior associated with the setter that you want to trigger, then the safest way is to put in in a private (i.e. never-overridden) method that’s invoked both by the initializer and by the setter. (Incidentally, a similar danger lurks in ‘dealloc’, too, but there’s no general rule that can be applied. Sometimes invoking a method is the correct thing to do, sometime accessing the ivar directly is correct. It varies case by case.) _______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
