<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Nachricht</TITLE>
<META content="MSHTML 6.00.2800.1126" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=2>> >> BTW, I am very seriously considering doing exactly
that -<BR>> >> get rid of the "visibility" of class object in
favour<BR>> >> of a global context.<BR>><BR>> Can you explain? I
do not understand but I'm intrigued.<BR><BR>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.<BR><BR></P>
<H3>The Problem</H3>
<P><FONT face=Arial color=#0000ff></FONT><FONT face=Arial
color=#0000ff></FONT><FONT face=Arial color=#0000ff></FONT><BR>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.<BR><BR>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'.<BR><BR></P>
<H3>Looking at it differently</H3>
<P><FONT face=Arial color=#0000ff></FONT><BR>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.
<BR><BR>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.<BR><BR>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 <EM>quite</EM> 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.<BR><BR>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.<BR><BR></P>
<H3>So then, why do we need Object?</H3>
<P><FONT face=Arial color=#0000ff></FONT><BR>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 <B>should</B> be part of one scope or another. Which effectively
means that Object really gets down to 'objectness', namely being purely defined
by identity.<BR><BR>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 <EM>really</EM> expose it
to the user???<BR><BR>In addition, what do we <EM>teach</EM> 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.<BR><BR></P>
<H3>Getting rid of Object in favour of a context</H3>
<P><FONT face=Arial color=#0000ff></FONT><BR>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 <EM>functions</EM>, the latter being <B>implemented</B> as methods
on what is now known as class Object.<BR><BR>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.<BR><BR>[Much more snipped away since I don't want it on a public
list]</P>
<P>Cheers,</P>
<P> - Andreas</FONT></P></BODY></HTML>