Let me summarize what I understand so far:

We have three different cases mentioned so far:

1) Object>>inform

Apparently some agree with me that this is bad form. This introduces a
hidden dependency on PopUpMenu. If you need a level of indirection for
flexibility, than create one for your app/module so you have control over
what your app is doing and can be aware of specific dependencies. If it
requires more flexibility across multiple applications (such as for logging
and such) then it may need to have it's own module (ie. a Logging module).

2) Object>>inspect

The difference here is that EVERY object is inspectable. There is no object
(so far as I know) that should not support this. So inspect being on there
isn't that strange to me.

For example all the Morph methods, shouldn't they be on some sort of
MorphBase class such that all Morphs would descend from that? This kind of
fits with the idea of Environment--but puts each object's environment at the
"right" level/scope. Only giving the necessary "environment" for the tree in
the hierarchy that needs it.

And I'll certainly admit that as I'm reading and learning, it seems that
multiple inheritance would be nice.

3) Object>>isFoo

What I'm hearing is that this is a mechanism to handle "interfaces" though
more general than what is generally provided in other languages. It's "can I
interact with you in a certain way". There are at least several ways I can
think of to do this:

  1. Object>>isFoo
  2. Put the isFoo only on objects that support it. Any querying object will
have to handle a potential NotUnderstood if the answer is no.
  3. Use Object>>respondsTo to see if the method exists.
  4. Use Object hasProtocol: Foo

There are probably other ways, so I guess my question is: why do it #1 when
it seems to result in some silly newcomer is calling a "bloated Object"?
What are the problems with the other ideas (and other ideas not listed
here)?

Another tidbit on that line from the byte article:
http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

"Polymorphism: A program should specify only the behavior of objects, not
their representation.

    A conventional statement of this principle is that a program should
never declare that a given object is a SmallInteger or a LargeInteger, but
only that it responds to integer protocol. Such generic description is
crucial to models of the real world.
    Consider an automobile traffic simulation. Many procedures in such a
system will refer to the various vehicles involved. Suppose one wished to
add, say, a street sweeper. Substantial amounts of computation (in the form
of recompiling) and possible errors would be involved in making this simple
extension if the code depended on the objects it manipulates. The message
interface establishes an ideal framework for such an extension. Provided
that street sweepers support the same protocol as all other vehicles, no
changes are needed to include them in the simulation: "

That makes it sound to me that they were assuming that protocols would be
the equivalent of interfaces. Which I think would suggest #4 above.

Thanks again for so much patience with me. I really appreciate the
information.

-joel