<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 23, 2013 at 5:28 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><span style="color:rgb(34,34,34)">See, I didn't want to get into this because your approach continues to</span><br>
</div>
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></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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...</blockquote><div><br></div><div><div>An instance of a given class will always have the same set of instance variables, right? And for that set of instance variables, there's some combination of values that a valid instance could have. So write a method that sets the variables to those values. Maybe some of the parameters will be nil. That's fine. The only requirement is that it leave the object in a valid state. I can't see how there's any case where it's not possible to do this. </div>
<div><br></div><div>On the other hand, sure, there may be cases where it's not convenient. In those cases, don't use Single Initializer. It's a pattern, not a commandment. </div><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><span style="color:rgb(34,34,34)">I have not see the example you refer to yet.</span></div></blockquote><div><br></div><div>Looks like the list-serv scrubbed it. Download it from here:</div><div><br></div>
<div><a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131223/08bcf9cb/Example-Initialize.obj" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131223/08bcf9cb/Example-Initialize.obj</a><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>>> So you think Point class>>x:y: should be #newWithX:y:?<br>
</div><div>
><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></blockquote><div><br></div><div>In a brand new Smalltalk with no legacy code, sure. It's a bit awkward, but given that we usually create points with x@y, it's fine. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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></blockquote><div><br></div><div>Single Initializer always expects the class that declares instance variables to provide a method for initializing them. Object provides an empty #initialize method, because it has no instance variables. I don't see where the library/application distinction comes into it, nor any inconsistency. Could you elaborate?</div>
<div><br></div><div>Hmm, are you saying that #initialize should set default values, which would then be replaced by values passed to a Constructor Parameter Method? Using Point as an example:</div><div><br></div><div>Point>>initialize</div>
<div> x := 0.</div><div> y := 0.</div><div><br></div><div>Point>>setX: xInteger y: yInteger</div><div> x := xInteger.</div><div> y := yInteger.</div><div><br></div><div>Integer>>@anInteger</div><div>
^ Point new; setX: self y: anInteger</div><div><br></div><div><br></div><div>That's reasonable, in that it never leaves the instance in an invalid state, but I don't like the repetition. If the creator of the point knows the values it wants, why not just set them once and be done with it?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We'll just have to agree to disagree.<br>
</blockquote><div><br></div><div>Sure, I'm happy to do so. I'm not trying to convince you to adopt my taste, just to stop rewriting my code to conform to yours.</div><div><br></div><div>Colin</div></div><br></div>
</div>