> >> BTW, I am very seriously considering doing exactly that -
> >> get rid of the "visibility" of class object in favour
> >> of a global context.
>
> Can you explain? I do not understand but I'm intrigued.

Below is an excerpt of some of my notes on this issue. Note: these were not
intended for publication, they're really just some private thoughts.




The Problem



Let's try to state the problem first. In many cases, we need some 'generic
action' to be available for any kind of object. Examples include #printOn:
methods like #isFoo and similar. I'm calling these methods 'generic actions'
since I don't want to imply any meaning with it for now. The 'problem' with
defining any of these is two-fold. For one thing, adding them directly to
class Object exposes these methods to a naive user browsing for information
about "what this system can do". That's problematic because it is
overwhelming and yet not really telling us something - if we look in class
Object then, really, we are looking at "naked objectness" which effectively
constitutes identity. Whether or not 'all objects can do X' is quite a
different question in this respect.

Most people are being terribly overwhelmed if they ever look at class Object
in this way. This leads to situation which we see in Squeak today where
people anxiously 'refactor' (in quotes for a reason) these methods to a
different place. They do this because they claim that 'an object should
represent objectness' (identity) and be 'minimal'.




Looking at it differently



If we look at the problem in a slightly different way, we can say that there
is only a SINGLE reason for wanting to add something to class Object -
namely to extend the ENVIRONMENT. 

I think this is an important conceptual difference. I can't say for certain
why this is the case but it seems that there's a general hesitation to add
some method to a 'class outside of your scope' but there is much less
hesitation to extend the environment, as long as it stays within the local
scope.

But what defines the 'locality' of scope here? Let's take an example which I
believe is representative for most of what is said here. If we make a
project consisting of two classes Foo and Bar then we typically have no
hesitation to add Foo and Bar to the environment. However, adding a method
like #isFoo to class Object is quite a different matter. What appears to be
different in the two cases is that when we make Foo and Bar they have a
common scope (most likely a system category in which we can find them)
whereas #isFoo - living in 'class Object' - is too far away to be considered
'local' and therefore easily forgotten.

If we would have a way to increase the 'locality' of these methods, I think
we could solve many problems at the same time. 'Pollution' of class Object
would no longer be a problem as the methods added to it might not even be
visible there. Understanding the system would be simpler as one can observe
the context in which a method is defined (if #isFoo were close to Foo and
Bar I could guess that it must be related to the two and see what they do).
Modularization and dependency tracking would be improved as well since it
were much less likely that I'd be using #isFoo if I haven't looked at the
place where Foo and Bar are defined.




So then, why do we need Object?



Considering the above, it almost seems as if every method in class Object
could be part of one scope or another, in fact that it should be part of one
scope or another. Which effectively means that Object really gets down to
'objectness', namely being purely defined by identity.

And, if that's the case what the hell do we need class Object for? If it is
merely an environmental context in which some methods are stored for the
sake of faster lookups, then should we really expose it to the user???

In addition, what do we teach people by exposing them to class Object? We
teach them about subclassing, namely that 'all objects have to be a subclass
of some other object' which means that we enforce the notion to use
subclasses for everything. Which most of us (I think ;) agree is a bad idea.




Getting rid of Object in favour of a context



What I want to do here, is to effectively change the POV when people look at
the environment. Right now, most people think that the (programming)
environment is made up exclusively of classes and to a lesser extent of
objects. If we remove class Object from the user's perspective then we end
up with an environment which consists of classes, objects, and functions,
the latter being implemented as methods on what is now known as class
Object.

Class Object should never appear to the user, in fact there should be no
such thing. A user should be perfectly free to define her own class object
if she wishes to. And, in addition, this user should be able to define
'functions' in the environment which are available for all objects.

[Much more snipped away since I don't want it on a public list]

Cheers,

  - Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030524/9eda45c3/attachment.htm