[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-

From: Andy Wingo
Subject: Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1
Date: Sat, 21 Nov 2009 19:22:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)


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.)


>>> 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
> Nice diagram! :-)

Followed up by :)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]