[Seaside-dev] basicNew

[Yann Monclair]

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 at dabbledb.com> wrote:

> On Mon, Sep 29, 2008 at 12:59 PM, Randal L. Schwartz
> <merlyn at stonehenge.com> wrote:
> >>>>>> "Avi" == Avi Bryant <avi at 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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20080929/8e89c19c/attachment.htm