[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eliminating dynamic slots
- To: Gregor.pa@Xerox.COM, macgreg@vaxa.isi.edu
- Subject: Re: Eliminating dynamic slots
- From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
- Date: Tue, 31 Mar 87 07:50:27 pst
- Cc: commonloops.pa@Xerox.COM
>as the basis for a knowledge representation system. We are forcasting
>that in future applications, knowledge base objects might have on the
>order of 5 to 20 slots which fit the notion of an instance slot, i.e., a
>slot which must have a value, while for the same object there may be
>hundreds of "potential" slots, each of which has an exceedingly low
>probability of having a value.
The solution to this is to simply use a slot to which is assigned an
object containing the slots which one wants to make dynamic. Thus:
(defclass knowledge-based-application-class
(slots-where-things-always-are NIL)
(slots-where-things-could-be :accessor dynamic-slot-access)
)
>If dynamic slots are eliminated, we will be forced to implement
>them ourselves. My guess is that an efficient implementation would
>rely on relatively low-level portions of the PCL code, and would thus
>be subject to update as new versions are released. What we would
Not necessarily. The metaclass kernel is specifically designed to
make this kind of thing easy.
>We would prefer to be PCL-users rather than PCL hackers (in the
>non-perjorative sense of the word), in the sense that we are hoping to
>utilize PCL without the necessity of learning its internals, especially
>right now, when the implementation is continuously changing.
Changes in the implementation are a problem at the moment. The
point of getting rid of the :dynamic option was to pair out functionality
which was costing people who didn't use it. The metaobject protocol
was specificially designed for easy customization of system internals,
so the amount of "PCL hacking" you'd need to do would be fairly trivial.
>The last glimpse we saw of the Common Objects/Classes standard said very
>little about metaclasses, not even remotely enough to enable one to
>define one's own metaclass based only the standard. In other words, the
>metaclass mechanism seems to be one of the less mature parts of the
>standard, and from our vantage point, using it might consume a great
>deal more time than we would like to spend.
It is true that the metaobject protocol is still under discussion, but
a basic interface is outlined in ANSI X3J13 document 87-003. I don't
think it would take as much time to do a dynamic slots metaclass as
you seem to think (tracking revisions is another matter). This is
speaking from experience, since I've already done a metaclass for
CommonObjects.
Jim Kempf kempf@hplabs.hp.com