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

Colin Putney colin at wiresong.com
Mon Dec 23 21:13:50 UTC 2013


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. If you have more than one, you're defeating the purpose. For
NetworkLocation, presumably you have just one variant stored internally.
Let's say it's the IP address. In that case, you'd have one initializer,
#initializeWithAddress:port: and two constructors, #newWithIpString:port:
and #newWithHostname:port:. The constructors would be responsible for
converting their parameters into the right form to pass to the initializer.

In the example I posted, Square uses this technique.


> So you think Point class>>x:y: should be #newWithX:y:?
>

No, because Point has been around forever, and changing it would create
pointless *cough* breakage.


> That is just not how most Smalltalk code is written.  I believe there
> is value to having unity with the rest of Smalltalk standards and
> conventions.
>

Yeah, but Smalltalk doesn't really have a strong convention for constructor
names. You see all sorts of conventions in the image and packages. But that
was just an interesting idea that occurred to me. Ignore it if you don't
like it.

What's important about that passage was the bit about constructors. Your
instinct to call the superclass constructor is spot on, but it should be
done on the instance side. So instead of #newWithPrefix: calling #new,
#initializeWithPrefix: calls #initialize.

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


More information about the Squeak-dev mailing list