I did not check the code. initialize on the class initialize the class itself (this method is invoked at load-time of the class). so in new super new initialize

this is not the initialize of the class side but of the instance side that is invoked (since super new returns an instance of the class).

Hope it helps.

Stef

On 31 août 05, at 18:00, Mariano Wahlmann wrote:

Hi, my name is Mariano Wahlmann, i'm using Squeak3.8 and I have a questions about LineMorph class:

Why exists the new method as class method instead of having an initialize method?. I ask this because if you want to extend this class, you have to re-write new and initialize methods. Is this maybe a bug?.

Thanks

Marcus Denker wrote:

Am 31.08.2005 um 22:01 schrieb Matej Košík:

...

Mariano Wahlmann wrote:

...

Hi, my name is Mariano Wahlmann, i'm using Squeak3.8 and I have a questions about LineMorph class: Why exists the new method as class method instead of having an initialize method?. I ask this because if you want to extend this class, you have to re-write new and initialize methods. Is this maybe a bug?. Thanks

I think, it is a bug. The LineMorph class from:to:color:width: should not refer directly to `PolygonMorph'. It disables the attempts to make subclasses of LineMorph.

I recommend you to use PolygonMorph directly (subclass it if you need). Under certain conditions, you could also use polygon-morph (or line-morph) instances directly, set up their properties and make them part of larger structures. Morphic has great (other may have different opinion) mechanisms for composing things. One only has to learn them. As comrade Lenin said, browse-browse-browse. :)

This mail enlightens why LineMorph is implemented this way...

http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/ 054537.html

for me, it is clearly a questioable design and should be fixed. But the authors disagree.

Marcus

I see. These (although for different project) situations are clearly commented in `clsguide.dvi' (I am currently reading), page 4, section 1.4 = Policy on Standard Classes. I am pasting it for anyone interested: --------------------------------------------------------------------- \subsection{Policy on standard classes}

Many of the problem reports we receive concerning the standard classes are not concerned with bugs but are suggesting, more or less politely, that the design decisions embodied in them are `not optimal' and asking us to modify them.

There are several reasons why we should not make such changes to these files. \item However misguided, the current behaviour is clearly what was intended when these classes were designed. \item It is not good practice to change such aspects of `standard classes' because many people will be relying on them. \end{itemize}

We have therefore decided not to even consider making such modifications, nor to spend time justifying that decision. This does not mean that we do not agree that there are many deficiencies in the design of these classes, but we have many tasks with higher priority than continually explaining why the standard classes for \LaTeX{} cannot be changed.

We would, of course, welcome the production of better classes, or of packages that can be used to enhance these classes. So your first thought when you consider such a deficiency will, we hope, be ``what can I do to improve this?''

Similar considerations apply to those parts of the kernel that are implementing design decisions, many of which should be left to the class file but are not in the current system. We realise that in such cases it is much more difficult for you to rectify the problem yourself but it is also the case that making such changes in the kernel would probably be a major project for us; therefore such enhancements will have to wait for \LaTeX3. --------------------------------------------------------------------- So more-or-less similar situations are completely normal. I do not know how they could be effectively solved to make everyone happy.

Regards