I think that the issue is of readability vs. efficiency. If you are writing code that needs to be efficient (at the cost of readability and ease of maintenance), you could do something like this: (option #1)

WAPoint class>>x: xNumber y: yNumber
^self basicNew initializeWithX: xNumber y: yNumber

WAPoint>>initialize
"make sure you also update #intializeWithX:y: if ever you modify this method"
super initialize.
x := 0.
y := 0.

WAPoint>>initializeWithX: xNumber y: yNumber
"this is a copy of #initialize, but I directly set x and y to the values I want, because I'm in a hurry here"
"any modification of #initialize should be also done here"
super initialize.
x := xNumber.
y := yNumber.

Note that I wouldn't try to link these methods. It's ugly code duplication, with the aim of speed.

If you didn't want extreme speed, but wanted rather readable code, I would recommend this: (option #2)

WAPoint class>>x: xNumber y: yNumber
^self new
         x: xNumber;
         y: yNumber;
         yourself

WAPoint>>#initialize
super initialize.
x := 0.
y := 0.

So doing it the clean (but maybe not optimal) way saves you one method and I think increases readability. You don't even need a comment to know what's happening.
Whereas the first example (the fast one) introduces one extra method, whose name isn't really appealing, and it also introduces code duplication, more maintenance effort, and the reason for having #initializeWithX:y: implemented that way isn't clear, so you need a comment to explain it, because you deviated from the "vanilla" #initialize model.

I would say the standard is option #2. The exception is #1, if you want speed at the cost of other things.

My 2 cents,

Yann

On Mon, Sep 29, 2008 at 9:20 PM, Avi Bryant <avi@dabbledb.com> wrote:
On Mon, Sep 29, 2008 at 12:59 PM, Randal L. Schwartz
<merlyn@stonehenge.com> wrote:
>>>>>> "Avi" == Avi Bryant <avi@dabbledb.com> writes:
>
> Avi> Assuming no other changes to my code, this means that super's
> Avi> initialize is not called when you use the #x:y: or #point: class side
> Avi> creation methods, but *only* when you use a bare #new.
>
> Well, that's why you don't call basicNew unless you really mean it.
>
> The problem is that you need to decide if you're doing it the Squeak
> way or not.
>
> What I described in my earlier post is the Squeak way, and the way
> I learned looking at the Smalltalk image in 1981.  If you want to
> do it the Objective C way, be prepared for some incompatibility.

Ok, I'm still looking for a *complete* example of the "Squeak way",
and none of your posts so far provide one, so let me set up a straw
man and you can tell me where it's wrong.

WAPoint class>>x: xNumber y: yNumber
 ^ self new x: aNumber y: aNumber

WAPoint>>x: aNumber y: yNumber
  x := aNumber.
  y := aNumber

WAPoint>>initialize
 super initialize.
 self x: 0 y: 0

The only interesting/contentious part of this, I think, is the very
last line, where #x:y: is sent from the overridden #initialize method.
 I believe you have to include it, because if you don't, then sending
"WAPoint new" ends up with an uninitialized instance (nil for x and
y).  If you do include it, however, you end up performing the
initialization twice - this is not a big deal when all you're doing is
assigning some instance variables, but you can certainly imagine cases
where doubly initializing an instance would be costly or incorrect.
That's why I don't like this approach, but if I've misunderstood it,
let me know.

Here's the alternative I'm proposing again, for reference:

WAPoint class>>x: xNumber y: yNumber
 ^ self basicNew x: aNumber y: aNumber

WAPoint>>x: aNumber y: yNumber
  super initialize.
  x := aNumber.
  y := aNumber

WAPoint>>initialize
 self x: 0 y: 0

This way, whether you use #x:y: or #new, you end up initializing the
instance exactly once - and I'm still unclear on what the concrete
disadvantages are.

Avi
_______________________________________________
seaside-dev mailing list
seaside-dev@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev