[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: Ludovic Courtès
Subject: Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1
Date: Sun, 08 Nov 2009 01:41:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)


Andy Wingo <address@hidden> writes:

> On Thu 05 Nov 2009 19:13, address@hidden (Ludovic Courtès) writes:


>> "Andy Wingo" <address@hidden> 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.


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

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


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

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!


reply via email to

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