Re: [GOOPS] Specializing <generic> to allow lazy method addition

[Mikael Djurfeldt <mdj@mit.edu>]

Andreas Rottmann <a.rottmann@gmx.at> writes:

>> (define-class <guile-gnome-generic> (<generic>)
>>    (temp-methods :init-value '()))
>> (define-method (add-method! (generic <guile-gnome-generic>)
>>                             (method <method>))
>>   ;; Note we don't call next-method
>>   (slot-set! generic 'temp-methods
>>              (cons method (slot-ref generic 'temp-methods))))
>>
> I tried to play around with this a bit and it seems it is not viable
> ATM; I experienced the problem described already in [0] and [1]. It
> seems noone has answered why %invalidate-method cache insists on a
> pure generic (from goops.c, in scm_sys_invalidate_method_cache_x):
>
>   SCM_ASSERT (SCM_PUREGENERICP (gf), gf, SCM_ARG1, FUNC_NAME);
>
> and what 'pure' generics are all about; FWICT, pureness is a flag set
> for all built-in generic classes. Would someone of GOOPS knowledge
> please be so kind to shed some light on this issue?

The mechanism which allows you to subclass builtin classes like
<generic> and specialize functions to them is called meta object
protocols, or MOPs.

While the MOP for <class> works, the MOP for <generic> isn't yet
implemented.  This is a shame and I've for very long had had the hope
to find time to fix it.  What we really quickly should do is to
document this situation so that people know that they cannot yet
subclass <generic>.

The purity flag, which you ask about, marks that a class is
"untouched" by the user so that the C runtime can count on specific
slots existing and residing at specific locations within an object.

The idea is that the runtime will look for specialized functions only
if the class isn't pure.

M



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user