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
|