[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: Re: a-to-c
- From: email@example.com
- Date: Mon, 18 Jun 90 10:52:59 +0100
- Cc: MOP.pa@Xerox.COM
- Sender: firstname.lastname@example.org
From Richard Barber, Procyon Research Ltd, Cambridge, UK
>Date: Mon, 11 Jun 90 09:45:44 PDT
>From: "Gregor J. Kiczales" <email@example.com>
>For any standard-metaobject, the implementation of the metaobject
>protocol can be heavily optimized. For example, a standard generic
>function metaobject doesn't need to ever call compute-discriminating-
>function. The rules of user specialization prevent there being any
>user-defined applicable methods.
>Formally, this optimization can be phrased as: The implementation is
>permitted to elide a specified call to a specified generic function if
>no portable methods would be applicable to the arguments.
Thanks for making this point more explicit. I had not realized the full
implications of this phrase when I originally read it in the MOP spec.
With this in mind I am now happy with the new spec.
I would guess that users of the MOP might also trip over this, expecting
compute-discriminating-function on a standard generic function to do the
full protocol when in fact the implementor has special-cased away the calls
to compute-applicable-methods and friends. I think perhaps there should be a
warning in the spec for compute-discriminating-function and also for
compute-effective-method etc. to say that if the user specializes any of
these functions then compute-discriminating-function may also need to
> The new specification of compute-discriminating-function is extremely
> constraining on the way implementations manage method dispatch in
> generic functions. In particular it forces the implementation to cache
> lists of applicable methods. We at Procyon have experimented with doing
> this but found it makes for an intolerable space overhead on small
>The description of the method lookup protocol was specifically designed
>to avoid requiring that lists of applicable methods be cached.
I intended my comment to say that an implementation which did not memoize
for standard generic functions would probably be unacceptably slow. But
this objection goes away given the special-casing in standard method
dispatch that is allowed to implementors.
> ... The new specification of
> compute-effective-slot-definition states that on each call it creates
> a new effective slot definition (using make-instance). However, Procyon's
> current implementation of CLOS shares these objects between a class and
> those inheriting from it whenever the objects would be equal.
>As far as I can tell, there are three ways to address this concern:
>1) Find a way to allow compute-effective-slot-definition to return an
>object not created by a call to make-instance.
At Procyon over the last few days we have worked out a way to simulate the
intended uniqueness behaviour of standard effective slot definitions without
actually calling make-instance every time. This solution preserves our current
space savings; we are therefore happy.
Thank you again for your clarifications, Gregor.