Re: Making every goops object applicable

[Mark H Weaver]

Hi Neil!

Neil Jerram <address@hidden> writes:
> Mark H Weaver <address@hidden> writes:
>> Krister Svanlund <address@hidden> writes:
>>> For example an instance of a class inheriting a class that inherits
>>> <applicable-struct> that defines 'procedure is not applicable.
>>
>> Looking at the code, it is clear that in order for a GOOPS instance to
>> be applicable, it is not enough for <applicable-struct> to be a
>> superclass.  It is also necessary for the _metaclass_ of its class to
>> have the SCM_VTABLE_FLAG_APPLICABLE_VTABLE bit set.
>>
>> One such metaclass is already built-in: <applicable-struct-class>, which
>> is the metaclass for <applicable-struct>,
>
> So the solution to Krister's problem is to make sure that every class
> he's interested in is defined as
>
>   (define-class <whatnot> (supers...)
>     ...
>     #:metaclass <applicable-struct-class>)
>
> Right?

That was indeed my suggestion, though your comments below raise an
additional complication that I hadn't considered: some additional magic
will be needed to ensure that the 'procedure' slot comes first.

>> but if you'd like to define
>> your own metaclass for applicable objects, you can set the bit manually
>> on the metaclass as described by Ludovic.
>
> Would this be needed, if the above works?

No, but since this is part of an effort to implement Python 3 in Guile,
it's possible that they may need to create their own metaclass for other
reasons.

>> However, keep in mind that the presence of that bit in the metaclass
>> indicates that the first slot of all instances _must_ be the procedure
>> slot.
>
> Might the (define-class ... #:metaclass <applicable-struct-class>)
> ensure that, by some kind of of compute-slots customisation...?

I guess so, but I'm not convinced that this is the right approach.  It
now seems reasonably clear that GOOPS has poor support for applicable
objects, so we should think about a more proper solution that's easy to
use.

I don't see why applicable objects should need a custom metaclass.  In
general, it seems to me that features that require custom metaclasses do
not compose well.  Subclasses of <applicable-struct> should "just work"
without users resorting to these hacks.

As I've suggested before, the most elegant solution I can think of is to
simply make a two-argument generic function called something like
'generic-apply'.  I suspect that there's some clever way to make this
very fast using the MOP, but I have yet to work out the details.
Unfortunately my copy of AMOP is 50 miles away at the moment.

Suggestions solicited, and if anyone wants to take the lead on this,
I'd be grateful.  If not, I'll try to come up with something.

     Thanks,
       Mark