Doug Evans <xdj...@gmail.com> skribis:
> On Fri, May 2, 2014 at 4:19 PM, Ludovic Courtès <l...@gnu.org> wrote:
>> Doug Evans <xdj...@gmail.com> skribis:
>>
>>> On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès <l...@gnu.org> wrote:
>>>> Doug Evans <xdj...@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’.
