trow@uw-june (Jay Trow) (09/07/84)
Forwarded from Smalltalk80Interest^@Xerox: --------- From: deutsch@xerox.arpa Date: 3-Sep-84 19:59:33 PDT Subject: How to 'classify' objects A problem that has plagued us for a long time has been how to classify objects. In its simplest form, it arises because some class X wants to know if an argument A it's been given is capable of performing according to protocol P. We tend to solve this problem in two ways, neither of them satisfactory: - (A isKindOf: Y), where Y is some abstract superclass that requires its subclasses to implement P. The problem here is that the test is tightly tied to a particular class hierarchy. This is a particularly severe problem without multiple inher- itance, since several classes may have to implement a protocol independently. - We define some new message, say understandsP, and then define it to return false in Object and to return true in all the places that implement P. The problem here is that Object gets all cluttered up with these messages, which runs against our preference for not having global conventions about the meaning of particular message names. What about the following idea: define a completely new, orthogonal space of properties or protocols. (Initially we'll probably represent them by Symbols.) Define the following message in Object: is: aProperty ^false Use the following kind of code for attributing properties to objects: (Integer) is: aProperty ^aProperty == #integer or: [super is: aProperty] This allows an arbitrary set of properties, no reliance on the class hierarchy, no clutter in Object. Property names continue to be global, which is the same problem we have with selector and class names now, but since property names are handled as objects rather than literals, it's even perfectly reasonable for an application to have its own internal properties (represented by objects other than Symbols) which won't interfere with system properties. Is this a familiar trick from the AI world? Are there better solutions out there we just haven't heard of? Let's hear about it.... ---------
rogerh@arizona.UUCP (Roger Hayes) (09/14/84)
Why not use (a series of) respondsTo: messages?
Do you intend to set up a completely separate "classification" scheme,
separate from the behavior of an object? What meaning would such a
"classification" have? I must not understand.
If you need to create objects which are distinguishable, you can put
isAFunnyThing methods in their protocols; then the test is
(object) respondsTo: #isAFunnyThing.
eg, to create FunnyThing integers,
classname FunnyInteger
superclass Integer
instance methods [
isAFunnyThing
^ true
]
Roger Hayes
University of Arizona
{ihnp4,ucbvax}!arizona!rogerh.UUCP
rogerh@Arizona.CSNET