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

Chris Muller asqueaker at gmail.com
Mon Dec 23 22:28:30 UTC 2013


>> 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.

See, I didn't want to get into this because your approach continues to
argue ways "it can be done" with Single Initializer and ignoring the
point I'm saying that sometimes there is an "either / or" scenario
that may not need, wish, or otherwise be-able-to, distill it down to
one single representation.

Maybe a requirement of the NeworkLocation is to be able to remember
exactly what the user specified to create it.  So it needs to keep the
original ipString or original hostnameString so that when they go back
to edit it they will see the familiar format that they entered and
prefer...

>  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.

I have not see the example you refer to yet.

>> 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.

I meant, "should".  I know you aren't crazy enough to try to actually
do it.  I simply meant, IF you were back in time and you were writing
that constructor, you would prefer it as #newWithX:y:.

If so, I guess we'll just have to agree to disagree.

>> 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.

Because "allocation of new instances of objects" is a _responsibility_
of the *class-side* and one of the things we vociferously argued about
years ago that this responsibility entails one thing, to #initialize
the object.  Your pattern takes that responsibility and, _sometimes_,
but not always, expects the end-users application to do it!  That's
quite a jump, and an inconsistent handling of the responsibility to
#initialize.

We'll just have to agree to disagree.


More information about the Squeak-dev mailing list