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

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Andy Wingo <wingo@pobox.com> writes:

> On Thu 05 Nov 2009 19:13, ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> "Andy Wingo" <wingo@pobox.com> writes:
>>
>>>     * libguile/deprecated.h (scm_vtable_index_vtable): Define as a synonym
>>>       for scm_vtable_index_self.
>>>       (scm_vtable_index_printer): Alias scm_vtable_index_instance_printer.
>>>       (scm_struct_i_free): Alias scm_vtable_index_instance_finalize.
>>>       (scm_struct_i_flags): Alias scm_vtable_index_flags.
>>
>> IIUC these are no longer negative indices, but why deprecate them?
>
> I think they are bad names. scm_vtable_index_vtable sounds nonsensical. 
> scm_vtable_index_printer prints instances, not the vtable itself.
> scm_struct_i_free is only valid on vtables, and is just a function that
> runs at finalization time, and doesn't actually free anything.
> scm_struct_i_flags is only valid on vtables.

OK, I agree.

>>>       (SCM_STRUCTF_FLAGS): Be a -1 mask, we have a whole word now.
>>>       (SCM_SET_VTABLE_DESTRUCTOR): Implement by hand.
>>
>> Likewise.
>
> It is now deprecated to access flags through a mask, because the mask is
> unnecessary. "Destructor" isn't mentioned anywhere else in Guile.

OK.

>>>     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?

>> -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?

>> -     (let* ((vtable (make-vtable-vtable "pr" 0))
>> +     (let* ((vtable (make-vtable "pr"))
>>
>> Does that mean that "hello" as a layout specifier was not detected as
>> erroneous?
>
> Yes. Later commits cause this to raise an error.

Nice.

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

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

Nice diagram! :-)

>> Sounds good to me.  It seems unlikely that these were used outside of
>> Guile.  What do you think?
>
> I think that's about right. But they correspond to a useful thing --
> applicable structs that are not generics. They'll come back, but with a
> less confusing name. (I hate that name, "entity".)

So do I.

Cool, thanks!

Ludo’.