the monopoly of classes

Aaron J Reichow reic0024 at d.umn.edu
Fri May 23 00:37:56 UTC 2003


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 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.

> 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.


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



More information about the Squeak-dev mailing list