Path: utzoo!attcan!uunet!crdgw1!betelgeuse!halvers
From: halvers@betelgeuse.crd.ge.com (Pete Halverson)
Newsgroups: comp.lang.lisp
Subject: Re: CLOS questions
Keywords: classes, discriminated records, public domain CLOS
Message-ID: <13103@crdgw1.crd.ge.com>
Date: 25 Oct 90 14:44:41 GMT
References: <28175@bellcore.bellcore.com> <2726886C.2C1B@wilbur.coyote.trw.com>
Sender: news@crdgw1.crd.ge.com
Reply-To: halverson@crd.ge.com (Pete Halverson)
Organization: General Electric Corporate R&D Center
Lines: 65

In article <2726886C.2C1B@wilbur.coyote.trw.com> Scott Simpson writes:
>In article <28175@bellcore.bellcore.com> David S. Miller writes:
>>(3) Is there any mechanism in CLOS for automatically classifying an
>>object into a class based on attribute values?

Not automatically, no.  That kind of functionality hasn't yet trickled down
from the high-end knowledge representation schemes (e.g. KRL, LOOM) to the
more mundane OOP languages.

>>
>>(e.g.) In [a] previous example, suppose the 'student' class has an
>>"athletic-prowess' slot.  If the value of that slot was set to 'high
>>for a particular instance, then I'd want that instance to be
>>classified into the 'athlete' class as well.
>>The best way that I can think of to handle this is to define a method
>>such as:
>>(defmethod (setf athletic-prowess) ((new-value (eql 'high)) ...)
>>	...classify this instance as an athlete...  )
>
>The problem is that you want to reclassify an object after creation
>time. The only way I know of doing this is to create a brand new
>object in a different class. 

The standard method CHANGE-CLASS can be used to mutate an instance into a
different class, calling the extendable generic function
CHANGE-INSTANCE-FOR-DIFFERENT-CLASS The default method removes old slots
and values and adds new ones, leaving any common slots alone.  There
doesn't seem to be any restriction about what classes of instances may be
changed into other classes (as long as they're all standard classes), so
presumably specializing an object class is no problem.

As Scott pointed out, you *do* need to create a combined class that uses
both STUDENT and ATHLETE, so your "classification" method might look
something like

(defmethod (setf athletic-prowess) ((new-value (eql 'high)) (student STUDENT))
  (change-class student 'STUDENT-ATHLETE))           

However, I suppose it might be possible for this method to define the
appropriate combined class *dynamically*, so that it would work for any class
with an ATHLETIC-PROWESS accessor.  The precise incantations for that
relate to the Meta-Object protocol, though, so they're still not fully
defined (and therefore not well supported in existing implementations).

>If you didn't create a brand new object, then anybody pointing to the old
>object would suddenly be pointing to a new object of a different type!

Sounds exactly like what David's asking for---the same object identity, so
that existing pointers remain valid, but a more restricted object type.

>Ada has this problem with dynamically allocated discriminated record types.
>Consequently, in Ada, you cannot change the discriminant after the record
>is dynamically allocated.

As has been pointed out quite recently in this newsgroup, Common Lisp is
not Ada (thank heavens), nor is it Eiffel.  Anyway, it sounds like David
wants a *restriction* on the original type, which, in those languages,
wouldn't necessarily break whatever type assumptions and invariants were
derived from the original instance type.

--
===============================================================================
Pete Halverson                        		    INET: halverson@crd.ge.com 
GE Corporate R&D Center	                      UUCP: uunet!crd.ge.com!halverson
Schenectady, NY                     "Money for nuthin' and your MIPS for free"