Hi! On Sun 08 Nov 2009 01:41, [email protected] (Ludovic Courtès) writes:
> Andy Wingo <[email protected]> writes: > >> On Thu 05 Nov 2009 19:13, [email protected] (Ludovic Courtès) writes: > >>> "Andy Wingo" <[email protected]> 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/
