> On Tue, 27 May 2003, Joel Shellman wrote:
> 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.

It's done the same way--instanceof.

> That way, anyone that
> implements the right methods will get treated the same, no matter where in
> the inheritance hierarchy they happen to be.

Which is what I said in the following paragraph.

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

Given that information, it seems to me even more strange to put #isFoo on
Object.

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

Ah, that's good to know.

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

This doesn't quite match up with the literature I'm reading about Smalltalk.
See my other post where I quote about "the meaning is in the receiver". That
refers to an object-centric view of things, not package centric.

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

I could understand this in a prototype-based system, but it still doesn't
make sense to me for in a class based system. Actually, I was considering
enhancing the Array type the other day in javascript (didn't seem like it
was going to work, though--IE 5.5 doesn't support that kind of thing I
think).

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

But why? Why do you need to "pollute the holy shrine" when those methods
could just as easily be somewhere within your own category? Generally, (I
think) any method you can put on one side of interoperability between two
classes, could be put on the other side instead (or with some class in
between). So deciding which class to put it on is simply choosing which one
makes the most sense.

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

Why not use introspection to provide that same functionality?

obj respondsTo: iAmAMorph.

What I really mean, is that it seems to me there are many ways to figure out
if something should be treated as a Morph. The one you are suggesting works,
but it also breaks modularity and so why not choose a different way that
satisfies both?

I was reading about the Modules package today and had the same thought. You
wouldn't need a special way to do modules if everyone coded "nice" (aka. in
a certain way that you wouldn't need modules :) Okay, that's too vague).
Being able to modify any object in the system is great and powerful, but
what about name collisions and such?

-joel