<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 23, 2013 at 1:01 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
>> Your home-brew version of CPM does the same thing,<br>
><br>
><br>
> If you need a name for it, let's call it the "Single Initializer" pattern.<br>
<br>
</div>Why, it has the same number of "initializers" as CPM. #initialize<br>
(for default values) and #initializeWith:... for constructor<br>
parameters.</blockquote><div><br></div><div>Because I find "your home-brew version of CPM" insulting. "Single Initializer" conveys the intent of the pattern pretty well, I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span style="color:rgb(34,34,34)">You have "self initialize" in all of your #initializeWith:... because</span><br></div>
you chose to call #basicNew instead of #new. It's a throwback to<br>
2002.</blockquote><div><br></div><div>Ah. Well, I'm not bothered by a single message send appearing in more than one place. </div><div><br></div><div>Think of #new as a 0-parameter constructor. It sends #basicNew to get an instance, then sends #initialize to initialize its state.</div>
<div><br></div><div>Now consider the #prefix: constructor that you changed in <span style="font-family:arial,sans-serif;font-size:13.333333969116211px">AddPrefixNamePolicy. It's a 1-parameter constructor, which follows exactly the same pattern as #new, extended to take a parameter: it creates an instance with #basicNew, then sends #initializeWithPrefix: to set up the instance's state. </span><span style="font-family:arial,sans-serif">EnvironmentInfo class>>name:organization:packages: also follows the pattern. It accepts 3 parameters, creates an instance with #basicNew and passes the parameters to the initializer. </span></div>
</div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Because Smalltalk has keyword messages, we can't include general parameterized constructors in the base image, because they wouldn't have descriptive names. They'd be called something like #newWith: and #newWith:with:with:. It's better to let people define their own constructors. </div>
<div><br></div><div>That gives me an idea, though. Instead of #prefix: and #<font face="arial, sans-serif">name:organization:packages:, these constructors should be called #newWithPrefix: and #newWithName:organization:packages:. That would be clearer because it mirrors the structure of the initialization messages. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">See, this debate is useful after all. </font></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">
<div>
>> 2) has #initialize getting<br>
>> called from any of half-a-dozen places rather than the ONE place<br>
><br>
> So? Sending a single message in more than one place is fine. It's what<br>
> messages are for.<br>
<br>
</div>When you're duplicating the same code over and over again ("self<br>
initialize") in all your subclasses, that should be a clue that you<br>
should inherit that behavior from the superclass instead of repeating<br>
yourself.<br>
<br>
That's the standard followed by the rest of the image.</blockquote><div><br></div><div>It looks like this is the crux of our disagreement. My response above applies here too.</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>
>> 3)<br>
>> doesn't factor the behavior of simply *constructing* a _well-formed<br>
>> object_ from the behavior of fully initializing it (i.e.., building up<br>
>> a large cache).<br>
><br>
> What are you talking about? None of the classes you've "cleaned up" has a<br>
> cache.<br>
<br>
</div>The CPM pattern covers general case, not just your classes.</blockquote><div><br></div><div>Ok, then what makes you think that Single Initializer can't deal with caches well? If you have a case where you need to populate a cache separately from initializing the object to *have* a cache, well, then write your initializer that way. </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>Let's move on because I have more important, _design-level_ criticisms<br>
</div>
of Environments to discuss.<br></blockquote><div><br></div><div>Sure, criticize away, I'm happy to discuss. But as long as you're committing your "clean ups" to the trunk, I don't want to just drop this. </div>
</div><br></div><div class="gmail_extra">Colin</div></div>