I see thanks for your explanation. I have the impression that your 
context looks like
a bit as a classBox extension where you would only to see the extension 
of Objects the classBox in which you are
and its parents did.

I think that what is interesting with all new ideas is to see how they 
scale because there are a lot
of stuff in Object or systemDictionary (that I know much better now) 
that are simply not at their place.
What is clear is that sometimes we need a kind of utility class.

Stef

On Saturday, May 24, 2003, at 01:42 PM, Andreas Raab wrote:

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