Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1

[Andy Wingo]

Hi!

On Sun 08 Nov 2009 01:41, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> writes:
>
>> On Thu 05 Nov 2009 19:13, address@hidden (Ludovic Courtès) writes:
>
>>> "Andy Wingo" <address@hidden> writes:
>>>
>>>>     Hidden slots.
>>>>     
>>>>     * libguile/struct.c (scm_make_struct_layout): Add support for "hidden"
>>>>       fields, writable fields that are not visible to make-struct. This
>>>>       allows us to add fields to vtables and not break existing make-struct
>>>>       invocations.
>>>
>>> My first reaction was that it may make the struct layout code yet
>>> hairier.  Would opaque fields be usable for that purpose?  In what sense
>>> does it attempt to “not break existing make-struct invocations”?
>>
>> Imagine you have a vtable vtable with an extra field. The make-struct
>> invocation to make a vtable of that vtable-vtable is (make-struct
>> vtable-vtable layout printer extra-field). Hidden fields allow us to add
>> more fields to e.g. all vtables -- like a name -- without having
>> "extra-field" being interpreted as that extra field.
>
> Understood.  And what’s the use case that prompted you to implement
> this?

Adding a field to all vtables -- a name. Most all vtables need a name.

>>> -typedef void (*scm_t_struct_free) (scm_t_bits * vtable, scm_t_bits * data);
>>> +typedef void (*scm_t_struct_finalize) (SCM obj);
>
> (Can you make sure these two type names appear in the log?  It makes it
> easier to search for them.)

OK.

>>> I’m slightly concerned about the incompatibility.  What’s the rationale?
>>> (I reckon that passing ‘scm_t_bits’ pointers to user code is not very
>>> elegant.)
>>
>> It was never documented, and only used by guile-gnome afaik. Better to
>> change it to do the right thing, then document it :-)
>
> I can’t help but think that if guile-gnome uses it, then others might as
> well use it.  Could you make it a separate patch?

Guile-GNOME only uses it because I grubbed about for months and months
and found it. It might be presumptuous, but I really don't think anyone
else knew about it.

But OK. I will try. I just hate revisiting that commit that I spent so
much time on :/

>>> (I’ve always thought that ‘make-vtable-vtable’ has no good raison
>>> d’être.  The GOOPS/CLOS model has only ‘make’, and it makes perfect
>>> sense to have a single procedure to “make things out of meta-things”.)
>>
>> A struct is an object. A vtable is a class. A vtable-vtable is a
>> metaclass. Metaclasses are themselves classes; and classes are
>> themselves objects. You need make-vtable-vtable to make a new strange
>> loop at the top, like <class> being an instance of itself.
>
> Hmm I don’t see why ‘make-vtable-vtable’ is required to make the loop.
> But that’s another story.

CLOS also has inherent metacircularities.

>> It's confusing a bit, and delightful :) See
>> http://wingolog.org/pub/goops-inline-slots.png.
>
> Nice diagram! :-)

Followed up by
http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile :)

The branch is finished now, btw. I intend to merge whenever I get time
to fix those patches.

Andy
-- 
http://wingolog.org/