<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 7:18 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">I almost entirely agree with you. Except that I think that calling</span><br>
</div></div>
#basicNew and initialising within the #initializeWithFoo: methods is<br>
superior because<br>
* you don't need a setter (as in, you don't need a method that looks<br>
and smells and tastes exactly like a classic<br>
expose-my-state-for-mutation setter.<br>
* #initializeWithFoo: tells you the ways you can construct a valid<br>
instance, and if you want to construct an _invalid_ one you have to<br>
work at it - actively subvert the API.<br>
* #initializeWithFoo: tells you much louder exactly what it will do,<br>
where #setFoo: (a) looks like a Java-style mutator and (b) suggests<br>
that you can (partly!) _reinitialise_ an object. Worse, #setFoo: only<br>
partially initialises the object, where #initializeWithFoo: completely<br>
initialises an object.<br>
<br>
So in the end we're arguing about two conventions that do more or less<br>
the same thing. I don't see any _improvement_ in using #new, and in<br>
fact see several (admittedly minor) downsides. So what's the point<br>
then of "fixing" this?<br></blockquote><div><br></div><div>Frank is exactly right. </div><div><br></div><div>This is a pattern that IIRC, Avi and Julian worked out in the early days of Seaside, with influence from Objective-C. Here's how it works:</div>
<div><br></div><div>1) each class that declares instance variables has exactly one initialization method</div><div>2) each initialization method must leave the instance in a valid state</div><div>3) each initialization method is named verbosely starting with 'initializeWith' and describes its parameters</div>
<div>4) each initialization method must call the initialization method of its super class</div><div>5) the super initializer probably has a different name (see #2), so we send it to self, not super, to allow overrides</div>
<div>6) there is one or more class-side constructors which send #basicNew and the initialization message</div><div><br></div><div>I've found that this is a subtle, but profoundly useful pattern. It eliminates the need for trivial setters just to get a valid instance created, which allows for better encapsulation of state and often full immutability. I've been using it long enough that I've started to see setters as a code smell. </div>
<div><br></div><div>Colin</div><div><br></div><div><br></div></div></div></div>