visibility" of class object in favour of a global context

Avi Bryant avi at beta4.com
Wed May 28 04:30:01 UTC 2003


On Tue, 27 May 2003, Joel Shellman wrote:

> Again, this doesn't make sense to me. I assume isFoo here is referring to
> "is this Object an instance of the Foo class".

Close.  It's actually closer in intent to "should I treat this Object as
an instance of the Foo class" - which is the key difference.  More below.

> But that's absurd to put that
> sort of method on Object, isn't it? Ie. in Java (yes, that's where I'm
> coming from) you would use instanceof, which should be easy in Smalltalk:
>
> (myObject class) == (Foo class)

Yes, in Java you would.  But if you were designing your Java code to be as
flexible as possible, you wouldn't be testing for a class, would you?
You'd probably be testing for an interface.  That way, anyone that
implements the right methods will get treated the same, no matter where in
the inheritance hierarchy they happen to be.

Smalltalk doesn't have explicit interfaces (perhaps you could argue that
it should), but #isFoo methods amount to more or less the same thing - if
an object wants to claim to be a Foo by implementing #isFoo to return
true, you should take it at its word, not be impolite and look at anything
so private as its class.  This allows, for example, Todd Blanchard to
implement a parallel ProtoMorph hierarchy that doesn't inherit any code
from Morphic, but still interoperates with it.

In general, it is considered bad form in Smalltalk to do *anything* based
on the class of an object, unless you're the method dispatch part of the
VM.

> I couldn't find quickly something that supports sub/super classes, but I
> imagine there is one. If not, would be trivial to write and I imagine would
> look something like:
>
> myObject class isSuper/isCoercible/isSubClass/etc.: Foo

myObject isKindOf: Foo.

> That's a specific case, I'm going to write up a more general post about my
> perception of Object interface bloatation (which seems one symptom of
> something I need to learn the name of).

One lesson that is important to learn when moving to Smalltalk, especially
from Java, is that classes are not units of modularity.  You shouldn't be
thinking about #isMorph as a method on Object, but rather as a method in
the Morphic package - and of course its not at all strange that Morphic
has methods like #isMorph, or that Morphic interacts Object, even
(in a Smalltalkers eyes, or at least mine) by adding methods to it.

I came to Smalltalk through Ruby and Objective-C, which make this lesson a
little easier, because the unit of modularity is very much the file
(which can contain as many definitions for as many classes as you like).
It didn't feel "dirty" to add a method to Object or Array because the
definition was very clearly contained within your code in your file, and
would only exist for your program or library.  In Smalltalk, it can feel
like you're polluting this holy shrine of "the image" when you add methods
anywhere but your own categories.  I think this because there's currently
very little tool support for indicating that #isMorph is in fact a method
in the Morphic package, and that if (for example) you unloaded Morphic,
that method should disappear as well.  I'm trying to fix that to some
degree with tools like PackageInfo, DVS, and Monticello.

The other common line is "why should every object in the system respond to
#isMorph"?  But, of course, you can always send any message to any object
you like.  If you happen to be sending #isMorph to some random object, I
would personally prefer that it return "false" than raise a
MessageNotUnderstood exception.

Hope this sheds some light.

Avi



More information about the Squeak-dev mailing list