[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
change to instance structure protocol
- To: Cyphers@jasper.scrc.symbolics.com
- Subject: change to instance structure protocol
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 3 Dec 1990 19:15:00 PST
- Cc: Moon@stony-brook.scrc.symbolics.com, email@example.com, MOP.PARC@xerox.com
- In-reply-to: "Scott Cyphers's message of Mon, 3 Dec 1990 08:49:00 PST <19901203164904.4.CYPHERS@SEAR.SCRC.Symbolics.COM>"
re: We do a blindingly fast linear search for the slot name in the table.
Ditto. Except that from monitoring things, I wouldn't have called it
"blindingly" fast; it isn't anywhere near as fast, for example, as the
(hashed-access) permutation-table indirection used for the "inline" case.
In our case the specialized method on SLOT-VALUE-ABUSING-CLASS implements
the optimization; but I can see that pulling it back into SLOT-VALUE for
"the standard metaclass" case could be worthwhile.
re: The bug (which could be fixed easily enough) is that you also have to
leave out slot names for any slots which are affected by a method on
SLOT-VALUE-USING-CLASS. There are a number of simple ways that . . .
But in general it's impossible to know what a random method on
SLOT-VALUE-USING-CLASS will affect, since one almost never specializes
the third argument (although you might specialize the second). Since
the _likely_ candidates for SLOT-VALUE-USING-CLASS methods will be
sublcasses of Standard-Class, then a less aggressive approach to
optimization might be good enough. That is, the "less aggressive"
approach would permit full speed on Standard-Class (where there would
be no user-defined methods), moderately fast speed on subclasses of
Standard-Class for which inapplicable methods exist, and of course
"correct, but slower" speed when the methods are applicable.
Now, the point of Gregor's original proposal (about which we are now
carrying on peripheral discussion?) was to alter the semantics of the
third argument so that the _unusual_ case would be more likely to have
methods specialized on something [e.g., DATABASE-SLOT-DEFINITION as
opposed to STANDARD-SLOT-DEFINITION]. This way, whatever optimization
winds up being used for "the standard case" would not be affected at all
by the presence of user-defined methods (ahem, presuming of course that
the loser didn't just leave the third argument totally unspecialized!)
Anyway, this kind of benefit make the proposal look even more attractive.
-- JonL --