visibility" of class object in favour of a global context

Joel Shellman joel at ikestrel.com
Wed May 28 04:38:42 UTC 2003


Let me preface this with: yes, I've just joined this list a week or two ago
and thus my questioning is not challenging, it's inquiring. Some of the
things said in this post really surprised me and so I really would like to
understand better.

Thanks!

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

It seems to me that the Object class being identity is most logical. It
should be the set of functionality that all Objects require/would find
useful.

> Most people are being terribly overwhelmed if they ever look at class
Object in this way.

Only because in Squeak it doesn't seem to be written according to that
guideline.

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

What's wrong with that?

> 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'm not sure I follow this. Many of the things I see on object just seem to
be shorthand stuff. Like the recent response to my post about self inform:
'hello'. It's just a shorthand for PopUpMenu inform: 'hello' or if you want
the flexibility he referred to, use MyExtraLevelOfIndirectionMenu inform:
'hello'. In this specific case, the problem may be that if he wants to
change where Object inform points to, he changes it for the entire
system--which is probably not what he really had in mind. Rather one would
want to do so for one's own application/module.

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

I would think that hesitation would be strongly encouraged to keep things
well organized.

> but there is much
> less hesitation to extend the environment, as long as it stays within the
local scope.

What's an example of extending the environment in local scope? Sorry, don't
understand what that means in Smalltalk code yet.

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

Hmmm.... why? You're referring to making the Foo and Bar classes accessible
by anyone, correct? I'm not quite following exactly, but it seems to me that
some level of organization/namespacing for classes would be helpful, though
perhaps not required. This would help significantly as far as conciseness in
understanding dependencies.

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

Perhaps this is because a method on a Foo is organized by a namespace (the
class Foo). Whereas a method on Object has no such organization and is the
equivalent of a global method (especially if it's a class method).

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

But then why put it in Object at all? Why not put it in a class that should
logically hold it?

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

See my other post about my understanding of #isFoo.

> So then, why do we need Object?

For identity, equality, maybe comparison, maybe a couple other things.
Basically: Object is to provide functionality that ALL objects have in
common. Shouldn't that be the guideline for any Class? Provide the behavior
common to all instances and subclass instances?

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

Exactly: put them each on an appropriate class.

> Which effectively means that Object really gets down to 'objectness',
namely being purely defined by
> identity.

Which is what it should be, shouldn't it?

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

Because there is some set of functionality that is commonly used by ALL
objects and thus belongs in the superclass of them all.

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

Whoa. Okay. I think I really don't "get it", then. Why is subclassing a bad
idea?

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

So you want global functions? Why? I've had to fight with some complex
Javascript over the last year and generally that's all most people use in
it--and it gets really messy when you get to any level of complexity.

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

It sounds to me like you're talking about adding a new concept to Smalltalk,
or at least the way it's written. One of the beauties of Smalltalk is it's
incredibly small number of base concepts (it was like 4 or something wasn't
it?). Why would you want to add another one?

Thanks in advance for your patience with me,

-joel shellman



More information about the Squeak-dev mailing list