A user (reader) of Object is being exposed to a complexity of Morphic 
(step) eToys (slotInfoButtonHitFor:inViewer:) and numbers (adapt...). If 
these were class extensions allowing some functionality to be accessed 
(String>>asUrl), then maybe it would be worth it. But the only reason 
these methods are there, AFAICT, are that this code was written before 
Traits were available, so the only way to allow any class to step 
without imlementing the framework in it, or using up its one inheritance 
slot was to put the framework into Object.

Such frameworks can now be placed each in a Trait, and composed in by 
those classes that choose to implement the required method.

Making all classes seem abstract because of this misplacement is the 
wrong solution, and hiding this workaround using another workaround in 
the tools is also the wrong solution.

Daniel

Randal L. Schwartz wrote:
>> "Daniel" == Daniel Vainsencher <danielv at tx.technion.ac.il> writes:
>>     
>
> Daniel> Please don't hide it - allow these design bugs to be fixed.
>
> I'm unclear about why you and the additional poster think these are "design
> bugs".
>
>