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

Colin Putney colin at wiresong.com
Sat Dec 21 21:56:34 UTC 2013


On Sat, Dec 21, 2013 at 1:01 PM, Chris Muller <ma.chris.m at gmail.com> wrote:

> > 1) each class that declares instance variables has exactly one
> > initialization method
>
> Well then you can't have more than one constructor type then.  Not all
> objects can follow a path down to a single constructor on the
> class-side that ends up calling #initializeWtih:...


Why not? I've never found this to be an issue.


> In several cases,
> you'll need #initializeWithThis: and #initializeWithThat:.  And, in
> both cases, you want to call #initialize from the top of them.  That's
> repeating yourself and unconventional.


Right. That's why the rule is one initializer.


> > 2) each initialization method must leave the instance in a valid state
>
> Of course, as does any initialization method like CPM methods.


Not so. If your class has ivars 'foo' and 'bar' and it needs both of them
to have values for the object to be valid, then neither #setFoo: nor
#setBar: leave the object in a valid state. You have to call both of them
to get a fully-initialized object. But #initializeWithFoo:bar: leaves the
object in a valid state.

> 3) each initialization method is named verbosely starting with
> > 'initializeWith' and describes its parameters
>
> The ONLY reason you call it "initializeWithThis:that:other:thing:"
> instead of "setThis:that:other:thing:" is because you want to repeat
> yourself by calling #initalize at the top of each method.
>

The reason to call it #initializeWithThis:that: is that it initializes the
object with this and that. If you like consider this an instance of
"intention-revealing selector".


> Also, your #1 said "exactly-one initialization method," but here you
> say, "each initialization method."


To quote in full, "each class that declares instance variables has exactly
one initialization method" so if you have more than one class, you'll have
more than one initializer.


> > 4) each initialization method must call the initialization method of its
> > super class
>
> So who calls "super initialize" then?
>

Whichever class introduces the first instance variables. Typically this
class inherits from Object, but that isn't necessary.

> 6) there is one or more class-side constructors which send #basicNew and
> the
> > initialization message
>
> Why basicNew instead of new?  Honestly, there's no good reason for
> that and it forces you to repeat yourself in all of your
> #initializeWith: methods.


Because #new calls #initialize. When following this pattern, #initialize
still gets called, but by a subclass initializer, not by the constructor.
We want to avoid calling #initialize twice.


> You and Frank both need to read the CPM pattern because you missed it.
>
 You're confusing CPM as a setter.


You're saying we should name methods #setFoo: to make it clear that they're
not setters?  Gimme a break. They're setters.

FWIW, I used CPM before Julian introduced me to this pattern. I think it's
better than CPM, and it pushes my designs in beneficial directions.

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


More information about the Squeak-dev mailing list