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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Dec 23 23:40:02 UTC 2013


2013/12/23 Chris Muller <asqueaker at gmail.com>

> >> 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.
>
>
No there are already different ways to initialize.
For example, take the collections, some of them #initialize: not
#initialize in order to pass a size (or capacity) to the initializer.
So the pattern used by Colin is pretty common in Squeak.
I invoked the case of Point more for the fact it sends basicNew instead of
new, than for the names.

There are indeed two different things on the table
1) to have a single initializer
2) the names chosen for initialization

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
http://en.wikipedia.org/wiki/The_Treachery_of_Images ;)

I suggest we concentrate on 1) - the single initializer pattern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131224/d852e66f/attachment.htm


More information about the Squeak-dev mailing list