<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/23 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">>> The reason I asked 'why' though was simply that 'Single', while maybe<br>
>> the 95% case, is not the case 100% of the time, so I think it's a<br>
>> misnomer for the name of your pattern.<br>
>><br>
>> You'd need more than one initializer whenever there's more than one<br>
>> way to create an object. Consider a NetworkLocation class -- which<br>
>> might be created with an IP OR a hostname. Whichever is specified,<br>
>> the other could be derived but doesn't really need to be. Therefore,<br>
>> you don't need to cram it all through one single initializer that<br>
>> parameterizes both. You need two: initializeWithHostname:port: and<br>
>> initializeWithIpString:port:.<br>
><br>
> No. Again, the whole point of the pattern is to have just one initializer<br>
> per class. If you have more than one, you're defeating the purpose. For<br>
> NetworkLocation, presumably you have just one variant stored internally.<br>
> Let's say it's the IP address.<br>
<br>
</div>See, I didn't want to get into this because your approach continues to<br>
argue ways "it can be done" with Single Initializer and ignoring the<br>
point I'm saying that sometimes there is an "either / or" scenario<br>
that may not need, wish, or otherwise be-able-to, distill it down to<br>
one single representation.<br>
<br>
Maybe a requirement of the NeworkLocation is to be able to remember<br>
exactly what the user specified to create it. So it needs to keep the<br>
original ipString or original hostnameString so that when they go back<br>
to edit it they will see the familiar format that they entered and<br>
prefer...<br>
<div class="im"><br>
> In that case, you'd have one initializer,<br>
> #initializeWithAddress:port: and two constructors, #newWithIpString:port:<br>
> and #newWithHostname:port:. The constructors would be responsible for<br>
> converting their parameters into the right form to pass to the initializer.<br>
><br>
> In the example I posted, Square uses this technique.<br>
<br>
</div>I have not see the example you refer to yet.<br>
<div class="im"><br>
>> So you think Point class>>x:y: should be #newWithX:y:?<br>
><br>
> No, because Point has been around forever, and changing it would create<br>
> pointless *cough* breakage.<br>
<br>
</div>I meant, "should". I know you aren't crazy enough to try to actually<br>
do it. I simply meant, IF you were back in time and you were writing<br>
that constructor, you would prefer it as #newWithX:y:.<br>
<br>
If so, I guess we'll just have to agree to disagree.<br>
<div class="im"><br>
>> That is just not how most Smalltalk code is written. I believe there<br>
>> is value to having unity with the rest of Smalltalk standards and<br>
>> conventions.<br>
><br>
><br>
> Yeah, but Smalltalk doesn't really have a strong convention for constructor<br>
> names. You see all sorts of conventions in the image and packages. But that<br>
> was just an interesting idea that occurred to me. Ignore it if you don't<br>
> like it.<br>
><br>
> What's important about that passage was the bit about constructors. Your<br>
> instinct to call the superclass constructor is spot on, but it should be<br>
> done on the instance side. So instead of #newWithPrefix: calling #new,<br>
> #initializeWithPrefix: calls #initialize.<br>
<br>
</div>Because "allocation of new instances of objects" is a _responsibility_<br>
of the *class-side* and one of the things we vociferously argued about<br>
years ago that this responsibility entails one thing, to #initialize<br>
the object. Your pattern takes that responsibility and, _sometimes_,<br>
but not always, expects the end-users application to do it! That's<br>
quite a jump, and an inconsistent handling of the responsibility to<br>
#initialize.<br>
<br>
We'll just have to agree to disagree.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">No there are already different ways to initialize.<br></div><div class="gmail_extra">For example, take the collections, some of them #initialize: not #initialize in order to pass a size (or capacity) to the initializer.<br>
</div><div class="gmail_extra">So the pattern used by Colin is pretty common in Squeak.<br></div><div class="gmail_extra">I invoked the case of Point more for the fact it sends basicNew instead of new, than for the names.<br>
<br></div><div class="gmail_extra">There are indeed two different things on the table<br></div><div class="gmail_extra">1) to have a single initializer<br></div><div class="gmail_extra">2) the names chosen for initialization<br>
<br></div><div class="gmail_extra">Chris, the name count, you can't rename initialize -> set and declare this is not a setter, it's quite surrealist and make me think of <a href="http://en.wikipedia.org/wiki/The_Treachery_of_Images">http://en.wikipedia.org/wiki/The_Treachery_of_Images</a> ;)<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suggest we concentrate on 1) - the single initializer pattern.<br></div></div>