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

Colin Putney colin at wiresong.com
Mon Dec 23 19:12:49 UTC 2013


On Mon, Dec 23, 2013 at 1:01 PM, Chris Muller <asqueaker at gmail.com> wrote:


> >> Your home-brew version of CPM does the same thing,
> >
> >
> > If you need a name for it, let's call it the "Single Initializer"
> pattern.
>
> Why, it has the same number of "initializers" as CPM.  #initialize
> (for default values) and #initializeWith:... for constructor
> parameters.


Because I find "your home-brew version of CPM" insulting. "Single
Initializer" conveys the intent of the pattern pretty well, I think.


> You have "self initialize" in all of your #initializeWith:... because
> you chose to call #basicNew instead of #new.  It's a throwback to
> 2002.


Ah. Well, I'm not bothered by a single message send appearing in more than
one place.

Think of #new as a 0-parameter constructor. It sends #basicNew to get an
instance, then sends #initialize to initialize its state.

Now consider the #prefix: constructor that you changed in 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.
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.

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.

That gives me an idea, though. Instead of #prefix: and
#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.

See, this debate is useful after all.

 >> 2) has #initialize getting
> >> called from any of half-a-dozen places rather than the ONE place
> >
> > So? Sending a single message in more than one place is fine. It's what
> > messages are for.
>
> When you're duplicating the same code over and over again ("self
> initialize") in all your subclasses, that should be a clue that you
> should inherit that behavior from the superclass instead of repeating
> yourself.
>
> That's the standard followed by the rest of the image.


It looks like this is the crux of our disagreement. My response above
applies here too.


> >> 3)
> >> doesn't factor the behavior of simply *constructing* a _well-formed
> >> object_ from the behavior of fully initializing it (i.e.., building up
> >> a large cache).
> >
> > What are you talking about? None of the classes you've "cleaned up" has a
> > cache.
>
> The CPM pattern covers general case, not just your classes.


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.


> Let's move on because I have more important, _design-level_ criticisms
> of Environments to discuss.
>

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.

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


More information about the Squeak-dev mailing list