the monopoly of classes

jan ziak ziakjan at host.sk
Thu May 22 21:57:08 UTC 2003


On Thu, 22 May 2003 15:25:25 -0500 (CDT), Aaron J Reichow wrote
> On Thu, 22 May 2003, jan ziak wrote:
> 
> > hi again. i want to ask why must everything in squeak be a subclass of
> > something. do you think it's rational?
> 
> What logic would there be in doing it any other way?
> 

i think there would be. you see, i have encountered some problems when 
working with class-ified object orientied languages and i think that those 
problems would have been solved if i had the option to choose whether to 
subclass or to create a "bare" object.

> In a comprehensively OO system like Squeak, it makes a lot of sense 
> to have a root class that is the ultimate superclass of everything else.
> ProtoObject and Object provide a lot of base support to the entire system;
> C++ has show us what a no-root system is like- why would we want 
> that? Why recreate the same functionality in every new root class 
> you create?

c++ is not an object oriented system (my opinion), so you cannot use it as an 
argument.

of course that it is more efficient not to recreate the whole functionality 
in case it is obvious that something is a subclass of something other. but 
this is your idea, i have not said that. you have driven me into the position 
that i want to (i cite you) "recreate the same functionality in every new 
root class...". but i have never said that. i just asked: why must everything 
in squeak be a subclass of something. i think that you imagined that i 
presuppose something - but that's not true.

> 
> Again I ask- what other way would you do it?  With no root class? 
> What advantages are there in that?  I see having a root class simply 
> as the only logical thing to do in a system like Squeak.  It doesn't 
> confine the user or programmer one bit, but provides a tremendous 
> amount of convenience and consistence.  Losing it would take this 
> away but without providing any new positives.
> 

again, you have written something i have never said. but nevermind.

all i want to have is: objects and myself, and nothing else. i have not said 
that one of the objects cannot be object "class", i asked why must all 
objects in the system share the same common behavior of object "Object". for 
example, SmallInteger is a subclass of Object - but the consequence is that 
SmallInteger-s have functionality which Object has but which has not been 
included in class Object in conjunction with SmallInteger-s. For example, 
class Object has method with selector "at:put:", but this method has nothig 
to do with Object nor with SmallInteger - that selector should not have been 
there.

> Regards,
> Aaron
> 
>   Aaron Reichow  ::  UMD ACM Pres  ::  
> http://www.d.umn.edu/~reic0024/ "one has a moral responsibility to 
> disobey unjust laws"  :: m. l. king jr.






More information about the Squeak-dev mailing list