Object: Identity vs. Environment

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Jun 3 01:26:30 UTC 2003


Joel Shellman <joel at ikestrel.com> replied to my message:
	> But *some* methods really can be given *anything*,
	> and for those methods it is perfectly legitimate to put the
	> discriminations they need in Object.
	
	Please give an example. If they have to make distinctions, than that means
	they're not able to accept *anything*.
	
That does not follow.  In fact, it is *because* they make distinctions
that they *can* accept anything.

A good example is the method Object>>isColor.
It's used in

    Color>>
    = aColor
        aColor isColor ifFalse: [^false].
        ^aColor privateRGB = rbg and: [
            aColor privateAlpha = self privateAlpha]

This method accepts ANY OBJECT WHATSOEVER as its argument.
It is only because it makes the distinction "is this a colour or not"
that it is able to do so.  For things that answer true to #isColor,
it checks their privateRGB and privateAlpha methods; for things that
answer false to #isColor it immediately returns false.

Comparisons are a common example, because we want (x = y) to be
allowed and return a sensible result whatever x and y are.

	> Note that "responds to a protocol" is the WRONG notion here;
	> the important question is not whether #PCDATA and &entity respond
	> to some protocol that other things don't, but whether Attribute
	> will accept them.
	
	"whether Attribute will accept them": how is that defined? Attribute should
	be able to accept anything that it can properly interact with, right? Which
	is another way of saying that it responds to a certain protocol.

Yes, but the central point is that while Attribute "knows" what that
protocol is, from the outside, _we_ don't, so we can't test for it.

It's rather like the Color>> = example, where the protocol in question
consists only of private methods that nobody outside the class has any
business even knowing the existence of.

	It will understand certain messages I plan to send to it when I
	have to interact with it.

No, it's not about the messages *you* send to it, but the messages
*Attribute* sends to it, which is a very different thing.

	That's a protocol/interface/set of
	methods/whatever you want to call it.
	
Indeed it is, but it isn't necessarily one KNOWN TO OUTSIDERS.

In any case, there is no way of testing for a protocol in Smalltalk
other than sending an #isFoo message.



More information about the Squeak-dev mailing list