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

Colin Putney colin at wiresong.com
Tue Dec 24 00:29:42 UTC 2013


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


> 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...


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.

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.


> I have not see the example you refer to yet.
>

Looks like the list-serv scrubbed it. Download it from here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131223/08bcf9cb/Example-Initialize.obj


> >> 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:.
>

In a brand new Smalltalk with no legacy code, sure. It's a bit awkward, but
given that we usually create points with x at y, it's fine.

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.
>

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?

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:

Point>>initialize
    x := 0.
    y := 0.

Point>>setX: xInteger y: yInteger
   x := xInteger.
   y := yInteger.

Integer>>@anInteger
   ^ Point new; setX: self y: anInteger


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?

We'll just have to agree to disagree.
>

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.

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


More information about the Squeak-dev mailing list