the monopoly of classes

Cees de Groot cg at cdegroot.com
Fri May 23 07:18:30 UTC 2003


On Thu, 2003-05-22 at 23:56, jan ziak wrote:
> 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.
> 
Well, you're probably confusing classes with platonically ideal
concepts. The selector should very well be there because it is the best
place for it to be. The idea of a class hierarchy is as much to find the
best place to put code in order to allow minimal duplication as it is to
make a nice picture of classification, and as far as I'm concerned if
these two conflict, the first pressure usually wins. 

Most objects in Smalltalk have instance var slots, so it makes sense to
include methods that play with that at the lowest level. That it makes
Object behave a bit like a collection and that you can indeed find some
exceptions where it seems a bit far fetched (immediate types like
SmallInteger) is not a reason to throw out the whole system. It is just
an indication that this virtual world is not perfect, which in itself is
completely unsurprising given the observation that all things of a
certain complexity are imperfect. 

It is possible to make a perfect programming environment. I know of
people that wrote perfect functional programming languages. Then they
scratched their heads, an invented imperfections like monads because
they could not find another way to have these perfect programs
communicate with the (stateful) outside world. 



More information about the Squeak-dev mailing list