[Openmcl-devel] CLOS make-instance :around behaviour
pc at p-cos.net
Sun Oct 19 16:46:37 EDT 2008
On 19 Oct 2008, at 22:40, Bob Hutchison wrote:
> Hi Pascal,
> Thanks. Comments and questions below...
> On 19-Oct-08, at 3:33 PM, Pascal Costanza wrote:
>> You're invoking undefined consequences.
>> See Section 126.96.36.199.2 in the HyperSpec, bullet 19: You're defining
>> a method on a predefined generic function (make-instance) which is
>> applicable when its only required argument is a direct instance of
>> a standardized class (here the class 'symbol, of which 'some-class
>> is an instance: (typep 'some-class 'symbol) => T).
> Never would have found that :-) Thanks.
>> Common Lisp implementations are allowed to take that restriction
>> into account and, for example, compile away the call to make-
>> instance and replace it with something more efficient in case the
>> first argument is a constant symbol (for example).
>> If you really need :around methods on make-instance, consider
>> defining your own metaclass using the CLOS MOP. But based on your
>> example, I have the impression that an :after method on initialize-
>> instance should be sufficient, which is generally preferable
> That example is simplified. What I'm trying to do is implement a
> cache like thing. If someone calls, say, (make-instance 'thing :id
> "abc") then if there is already a thing with id "abc" return it
> rather than a new instance.
> As far as I know there's no way to change the return value of the
> primary method just using an :after method.
> So... I suppose either I define my own metaclass (a new adventure
> for me :-) or stop using make-instance.
> Better ideas?
Stop using make-instance is not a bad idea. You could define your own
create-instance function (or so), or shadow cl:make-instance in your
own package to replace it with your own version. If the caching
functionality is the only functionality you want to add, the CLOS MOP
may be too big a weapon for this purpose.
Are you sure that you need such caching? Garbage collectors are
nowadays pretty good at recycling short-lived objects, so that you
shouldn't need this for performance purposes - unless this is about
semantics and not performance...
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
More information about the Openmcl-devel