Re: Identifying what's usable in installed headers [was Re: RFC: Foreign objects facility]

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

Doug Evans <xdje42@gmail.com> skribis:

> On Fri, May 2, 2014 at 4:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Doug Evans <xdje42@gmail.com> skribis:
>>
>>> On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> Doug Evans <xdje42@gmail.com> skribis:
>>>>
>>>>> While function declarations are markable as being internal/external in
>>>>> published headers (SCM_INTERNAL vs SCM_API), macros are not.
>>>>
>>>> Internal macros are marked by a naming convention: they are prefixed by
>>>> ‘SCM_I’.
>>>
>>> Hi.  Sorry, catching up on mail.
>>>
>>> So this means that struct.h:SCM_STRUCT_* are ok to use by apps, right?
>>
>> You got me.  ;-)
>>
>> These ones are not documented, and some of them are clearly too
>> low-level and expose too many implementation details (flags, indexes,
>> etc.)
>>
>> ‘SCM_STRUCTP’, ‘SCM_STRUCT_SLOT_REF’, and a few others may be OK, but
>> there are equivalent public functions anyway, so it’s better to use
>> them.
>
> Thing is, the public functions (scm_struct_ref/set_x) are not
> equivalent (to SCM_STRUCT_SLOT_*).
> Plus the public "slot accessing" functions use the SCM_STRUCT_DATA
> interface. :-)
> SCM_STRUCT_SLOT_* isn't used at all in struct.c.
>
> $ grep SCM_STRUCT_SLOT struct.c | wc
> 0 0 0

Right.  Well, I don’t know what the intent was, and C-x v g tells me we
should ask Andy.  Andy?  :-)

Interestingly, commit b6cf4d02, which added this, also has this bit:

    Remove foreign object implementation.
    
    * libguile/goops.h:
    * libguile/goops.c (scm_make_foreign_object, scm_make_class)
      (scm_add_slot, scm_wrap_object, scm_wrap_component): Remove, these
      were undocumented and unworking.

Ludo’.