[squeak-dev] The Trunk: Environments-cmm.37.mcz

Colin Putney colin at wiresong.com
Sat Dec 21 15:58:54 UTC 2013


On Sat, Dec 21, 2013 at 7:18 AM, Frank Shearar <frank.shearar at gmail.com>wrote:


> I almost entirely agree with you. Except that I think that calling
> #basicNew and initialising within the #initializeWithFoo: methods is
> superior because
> * you don't need a setter (as in, you don't need a method that looks
> and smells and tastes exactly like a classic
> expose-my-state-for-mutation setter.
> * #initializeWithFoo: tells you the ways you can construct a valid
> instance, and if you want to construct an _invalid_ one you have to
> work at it - actively subvert the API.
> * #initializeWithFoo: tells you much louder exactly what it will do,
> where #setFoo: (a) looks like a Java-style mutator and (b) suggests
> that you can (partly!) _reinitialise_ an object. Worse, #setFoo: only
> partially initialises the object, where #initializeWithFoo: completely
> initialises an object.
>
> So in the end we're arguing about two conventions that do more or less
> the same thing. I don't see any _improvement_ in using #new, and in
> fact see several (admittedly minor) downsides. So what's the point
> then of "fixing" this?
>

Frank is exactly right.

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:

1) each class that declares instance variables has exactly one
initialization method
2) each initialization method must leave the instance in a valid state
3) each initialization method is named verbosely starting with
'initializeWith' and describes its parameters
4) each initialization method must call the initialization method of its
super class
5) the super initializer probably has a different name (see #2), so we send
it to self, not super, to allow overrides
6) there is one or more class-side constructors which send #basicNew and
the initialization message

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.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131221/26f5aa7b/attachment.htm


More information about the Squeak-dev mailing list