[closer-devel] interesting contextl use-case

[Attila Lendvai]

> I don't fully understand what you are asking for, but let me make
> some guesses. ;)

yes, you did! :)

> In ContextL, the various slots from partial class definitions that
> contribute to a layered class are always allocated in instances of
> that class. However, as in CLOS, you always have control over whether
> they are actually bound or not. I have thought about making
> allocation of such slots variable, but I have decided against because
> (a) I don't expect the memory overhead to be substantial enough to
> warrant a more complex solution and (b) it's always easy to add
> optional slots with another metaclass that uses hashtables in the
> background (one of the standard CLOS MOP examples). It should be
> relatively straightforward to add this to ContextL at the user level.

there are plenty of these CLOS objects (persisted in an RDBMS). and
the algorithm i'm talking about is a report generation. so it's not a
good idea for us to add each cache slot needed by the various report
generators for each instance, whether it was created while inside the
report generation or not.

but on the other hand we don't want make-instance to be slow either,
so eventually we'll dig deeper into this. for now the hashtables will
do.

but i would be very grateful if you could give me some links/hints on
how the hashtable based slots work! i always thought that it's a
deficiency of CLOS that the slot accessor atom (namely
SLOT-VALUE-USING-CLASS) is dispatching on the effective slot instance,
so there's no way to create a CLOS metaclass that has a working
CL:SLOT-VALUE and can have a variable number of slots stored in a
hashtable; e.g. the set of slot names not know at definition time.

and thanks for the detailed answer!

-- 
 attila