Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.clos
Subject: Re: accessing clos objects
Message-ID: <4127@skye.ed.ac.uk>
Date: 13 Feb 91 17:11:14 GMT
References: <9102121807.AA16036@cheops.cis.ohio-state.edu> <9102122248.AA22313@kolyma>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Distribution: inet
Organization: AIAI, University of Edinburgh, Scotland
Lines: 29

In article <9102122248.AA22313@kolyma> jonl@LUCID.COM (Jon L White) writes:

>On the other hand, with many implementations, there may be a
>performance penalty to pay if you use the approach that overrides
>the MAKE-INSTANCE method on STANDARD-CLASS.

I'm glad to see someone defending (in a sense) the vanilla
mixin approach as compared to the now so fashionable metaclass
method.  (Indeed, one advantage of CLOS over TELOS (the EuLisp
Object System) is that it's friendlier towards multiple inheritance
so that mixins are something you can expect to use.)

Anyway, one thing I've wondered about the MOP approach to slot access
is how slow access to slots of some new slot class would be.  How much
optimization could be done?

>                                        In your example, you
>have a method on INSTANCE-RECORDING-CLASS that "overrides" the
>one on STANDARD-CLASS. [Note: recent metaboject proposals define
>"extends" and "overrides" in more technical terms, and in that
>terminology, "extends" is the corect word; but without requiring
>every reader of this list to read these documents, I think "overrides"
>is more intuitively clear.

Some sort of distinction is needed, because it makes a big difference
whether defining a new methed breaks the way things currently work
(so that all slot access must be de-optimized, for example).

-- jeff