On Thu, 22 May 2003 19:37:56 -0500 (CDT), Aaron J Reichow wrote
> On Thu, 22 May 2003, jan ziak wrote:
> 
> > 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.
> 
> I'm not sure if you understand how Squeak or Smalltalk works.  It 
> would be possible to create bare object in Squeak, but the object 
> would NOT be useful. Squeak is a system which implements the language in 
> itself- it is a Smalltalk system written in Smalltalk.  It is not 
> Ruby or Python or C++, where the bulk of the language is all written 
> in C, with all the support for the existence of objects, sending 
> methods, etc. In Squeak, all of this is dependent on the Smalltalk 
> language itself.  The classic paradox of Classes... Every object has 
> a class.  Classes themselves are objects.  A classes's class is 
> another object which in turn ... has its class.
> 

... and C compiler is written in C compiler. but this is what i want to 
mention: squeak is not written in squeak, C compiler is not written in C 
compiler. in both cases, both objects are DISTINCT and not the same. it seems 
that you do not want to try to look at things (just for a while) in the way i 
view them: according to my opinion, it is impossible to really write squeak 
in squeak (similarily with the problem of self-reproduction). squeak is 
written in a system that incidentially has the name "squeak" - nothing more, 
nothing less.

> > c++ is not an object oriented system (my opinion), so you cannot use it
> > as an argument.
> 
> Heh.  Your opinion seems that nothing is an object oriented system except
> the real world.  You could reduce any possible debate into such 
> sillyness- what's the point?
> 
> > 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.
> 
> With Squeak you have objects and nothing else.
> 
> No one has said that there isn't kruft in Squeak- there most 
> certainly is. Object>>#at:put: may not be part of this kruft, I've 
> not looked into see what it does.  However, since a SmallInteger is 
> *an Object* it only makes sense for all SmallIntegers to inherit the 
> functionality Objects have.
> 

so why i cannot "turn off" the #at:put: method in SmallInteger ? i say you 
why: because of the subclassing and the way how it is used. wouldn't it be 
nice to have the option to decise whether i want to inherit a method or not ? 
i think it would be nice, but i have never seen any class-fied object 
oriented system capable of it. this is also one of the points of my critique 
of "bare" subclassing.

> Regards,
> Aaron
> 
>   Aaron Reichow  ::  UMD ACM Pres  ::  
> http://www.d.umn.edu/~reic0024/  "the question is no longer between 
> violence and non-violence; It is between non-violence and non-
> existence."  :: martin luther king junior