Re: Guile foreign object interface

[Ludovic Courtès]

David Kastrup <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Andy Wingo <address@hidden> skribis:
>>
>>> I am not so sure about about this one.  I think it's not accurate to
>>> characterize beginning to replace a 25-year-old C API (SMOBs) as
>>> "churn".
>>
>> I think the point is that there’s lots of code out there that rely on
>> SMOBs and we shouldn’t break it overnight, precisely because that API
>> is this old.
>>
>> Of course, I agree that pushing users towards an improved API is the
>> right thing long term, no argument here.
>
> Shrug.  LilyPond has all of its SMOB usage condensed into few C++
> classes, so it is comparatively easy to migrate to a different API as
> long as it offers comparable functionality.
>
> Which it doesn't (namely the ability of marking objects reached through
> STL-managed data structures).  So it's pretty pointless to "push users
> towards an improved API" and hardly "the right thing".

Thanks for your feedback, this is a kind of use case we’d like to
support.

I’m sure we already discussed it and then I forgot, but would anything
prevent the use of specific C++ allocators in this case?  The STL data
structures could be allocated on GC-scanned memory, in which case mark
procedures are unneeded.

If this cannot be done, there’s always the possibility of having a weak
hash table to keep the C++ and Scheme object life cycles in sync.  That
happens even with C APIs that record a pointer to an object we care
about in non-scanned memory.  Since 2.0 was out I’ve never used mark
procedures for in C bindings.

Thoughts?

As an aside, please keep the tone friendly as is the norm on this
mailing list.

Thanks,
Ludo’.