Re: Clos question
On 30 Nov 2007, at 10:34, Denis Pousseur wrote:
>
> Hello,
>
> I would make some sort of alias object, where all the slots are
> shared with
> the original object and only one slot is local (for instance to
> maintain a
> different position of the object on the screen).
>
> The Clos system doesn't seem to allow this, excerpt if the object is
> also a
> class (shared slots). It is not the case here : the class has several
> instances, each of them should have alias.
>
> Making a new class with two slots, one to contain the original
> object and
> the other to contain the local slot is possible but add a lot of
> complexity
> for slot access, and also for specialization of methods (because
> this class
> could not be a subclass of the original class : it needs only two
> slots and
> the original class has a lot of slots). I already have many
> functions witch
> access to these slots, some time using 'with-slots' or 'slot-value'
> and not
> with accessors... So I'm looking for a solution witch preserve my
> current
> codes at maximum.
>
> Any hints will be very appreciated. Thanks by advance
However, this kind of alias objects is typically described as wrappers
or delegating objects. Delegation between objects is one of the
trickier things to get right on top of the CLOS MOP and has a lot of
nasty corner cases. My gut feeling tells me it's better to look for a
different solution (but I may be wrong, maybe your case is much
simpler - I'd just be very careful here).
Your observation that classes already do what you need is right on
spot, and I would rather try to take advantage of that. The general
direction would be: Instead of defining classes and create instances
thereof in the usual way, you could as well define metaclasses and
create instances of such metaclasses - but you treat the latter as
plain objects, not actually as classes. In the metaclasses you can
define shared slots and instance slots for their instances as before,
but additionally, each metaclass instance can define their own shared
slots which, due to your changed perspective, are actually object-
local slots that can be shared between objects by making them inherit
from each other.
A drawback of such an approach is that classes are typically always
named and, more importantly, typically never garbage-collected. In
principle, CLOS and the CLOS MOP allow for creating anonymous class
objects, but some CLOS implementations have problems with that
(because presumably they haven't taken that option serious enough, and
CLOS is already hard enough to implement anyway ;).
Nevertheless, yes, I think I would go the latter way, especially
because I already tried to implement delegating objects with the CLOS
MOP, and the result of that was pretty ugly and hard to understand...
I hope this helps.
Pascal
--
Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium