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
-- 
Matej Košík