Object: Identity vs. Environment

Joel Shellman joel at ikestrel.com
Tue Jun 10 06:28:37 UTC 2003


> Joel Shellman <joel at ikestrel.com> continues the thread,
> which I am getting tired off.

Oops, sorry!

> The isEmpty is not a good example: that is a different concept.
>
> Why?
>
> The question at issue is precisely the same for #isNumber and #isEmpty:
> "does it make sense to send thus-and-such a message to this object NOW?"

Not exactly. #isEmpty is querying the current state of a Collection, similar
to distinguishing the #isTransparent and #isOpaque properties. #isNumber is
querying, "can I treat you like a number". Though I suppose they may have
the same "super" concept, they are quite different questions.

In other words, if #isEmpty returns true, I can call #add to change that. If
#isTransaparent is true, I can set #transparent: false or something like
that to change that. But if #isNumber is false... well, there is probably no
well defined way to change that instance to return otherwise (#asNumber
doesn't do that--that most likely returns a different instance).

> The other example makes some sense, but... why would you want to
> put isBeautifulWoman and isWolf on Object?
>
> Nobody ever said you would.  I certainly wouldn't.  There is some class
> (perhaps DiscWorldMoralAgent) or cluster of classes that they belong to.
>
> Part of the point that I was making is that precisely the same questions
> about the placement and appropriateness of isFoo messages DO arise
> lower down in the class hierarchy than Object; there is nothing at all
> special about Object in this discussion.

Well, there is in my initial question (oh so long ago no wonder you're
tiring of it). I certainly have no problem with #isFoo methods per se--it's
just that why are they on Object? That was the primary smell I thought I
smelled to start with.

> It sounds like you're agreeing with me that #isFoo is smelly.

Sorry, what I meant with this is: #isFoo--Foo is a non-system (ie. not
Float, Number or other such things) capability and I should have put "on
Object" in that sentence.

ie. "It sounds like you're agreeing with me that putting #isFoo for
arbitrary domain capabilities on Object is smelly (ie. isWebBrowser,
isMorph, etc.).

> The whole point that I keep on trying to make, and some people don't
> seem to get at all, although it isn't very complicated, is that
>     #isFoo messages as such are fine;
>     *any* messages in Object deserve to be looked at really really hard;
>     *some* messages which look as though they don't belong in Object
>         really don't, but the right way to get rid of them is not to
>         put them back in disguise, but to consider each such message
>         very carefully and refactor;
>     *some* messages which look as though they don't belong in Object
>         are actually quite harmless and would be hard to replace without
>         making things worse.
>
> So... what I'm hearing from you is that you agree with my
> suggestion #2--that #isFoo's should go in an appropriate place
> in the hierarchy and not in Object.  Right?
>
> *NO*.  What I'm saying is that for *SOME* #isFoo messages,
> Object *IS* the right place, but for *SOME* it isn't.

Sounds fine.

I guess the question remaining: "for which ones is Object that right place"
and my guess is there would be primarily two answers:

1) Anything that conceptually applies to all objects or is sufficiently
"fundamental" to the system.
2) Not putting it on Object would result in a sufficient mess as to justify
it.

And it's probably not that important to determine which is the right
question because both would likely result in nearly the same set.

-joel



More information about the Squeak-dev mailing list