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

Colin Putney colin at wiresong.com
Tue Dec 24 00:52:52 UTC 2013


On Mon, Dec 23, 2013 at 5:13 PM, Tom Rushworth <tom.b.rushworth at gmail.com>wrote:

> On 13-12-23 13:13 , Colin Putney wrote:
> > On Mon, Dec 23, 2013 at 3:34 PM, Chris Muller <ma.chris.m at gmail.com>
> wrote:
> >
> >
> >> The reason I asked 'why' though was simply that 'Single', while maybe
> >> the 95% case, is not the case 100% of the time, so I think it's a
> >> misnomer for the name of your pattern.
> >>
> >> You'd need more than one initializer whenever there's more than one
> >> way to create an object.  Consider a NetworkLocation class -- which
> >> might be created with an IP OR a hostname.  Whichever is specified,
> >> the other could be derived but doesn't really need to be.  Therefore,
> >> you don't need to cram it all through one single initializer that
> >> parameterizes both.  You need two:  initializeWithHostname:port: and
> >> initializeWithIpString:port:.
> >
> >
> > No. Again, the whole point of the pattern is to have just one initializer
> > per class.
>
> I understood the pattern (coming from an Objective-C developer
> viewpoint) not so much as having _one_, as having one _designated_
> intiailizer that handles the most general case, dealing with all the
> instance vars, any consistency issues, internal state etc.  It's fine to
> have other initializers for special cases, but they must call the
> designated one.
>
> To use Point as a probably too simple example, the designated
> initializer would be something like the existing:
>
>    Point class>>x:y:
>
> and then you might have another initializer something like
>
>    Point class>>initAtIntersectionOf: line1 with: line2
>
> but that method must call x:y:.  The pattern is that you have as many
> initializers as makes sense, but they all end up calling the designated
> one.  Some of the initializers may just supply default values, some may
> do conversions from other objects, whatever makes sense for the problem
> at hand.
>
> Since Objective-C was starting fresh and didn't have an image to give
> history so much weight :), they got to adopt a convention that all such
> methods started with "init", and the methods corresponding to "new"
> started with "alloc".  I think alloc and init make the roles clearer,
> but that's the benefit of hindsight :).


Hi Tom,

That's a good point. I've perhaps been overly emphatic about having just
one initializer; perhaps the pattern ought to be called "Designated
Initializer" instead. I think part of this is that the common Objective-C
idiom of "[[SomeClass alloc] init]" isn't used in Smalltalk—we always
extract that into a class-side constructor. Given that, it makes sense to
do the necessary transformations in the constructor, and then have it call
the designated initializer with parameters of the correct form. But sure,
having #initializeAtIntersectionOf:with: (as an instance method!) call
through to #initializeWithX:y: wouldn't bother me at all.

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


More information about the Squeak-dev mailing list