[Pdx-pm] Designing a C library specifically for HLL binding

[Eric Wilhelm]

# from chromatic
# on Thursday 30 October 2008:

>>     pointstruct * a_point;
>
>There's a crash waiting to happen.

Ah, that's good to know.

>        pointstruct a_point;
>...
>        get_polygon_point(fds, i, &a_point);

>Like I said though, if sizeof( pointstruct ) ever changes, you'll have
> to recompile this XS against the new headers (for Perl 5 bindings) or
> regenerate the PIR code that builds a pointstruct from the headers
> and a ManagedStruct PMC in Parrot.

What if I forgo the "shared library" bit and just go with something 
like "#include foo.c"?  Can I then sidestep the encapsulation 
police?  :-)

>If you instead wrote:
>        pointstruct *p = new_pointstruct();
>        ...
>        free_pointstruct(p);
>... and kept that API the same, and never allowed anyone to access
> struct members directly, you wouldn't have to recompile and you'd be
> free to rearrange and manipulate struct members between versions of
> your library all you want.

Given that the "library" is only intended as an organizing principle to 
provide sanity to the binding, is it worth the run-time penalty for 
this encapsulation?  I'm assuming here that there must be a non-zero 
number of operations (which would also include accessors to each of the 
x,y,z members of the struct, no?) and that there's not somehow a 
magically zero cost to this encapsulation.  What is the trade-off in 
making it a truly "shared" library?  Some memory savings when more than 
one app is linked to that .so (and not simply more than one perl 
process because that XS is itself a .so, right?)?  Unless I'm missing 
something in that set of factors (which is quite possible), it hardly 
seems worth running (and writing) the extra code to encapsulate access 
to the structs which only exist to keep the thing from being a 
(lexical) monolith of XS.

And yes I'm trading everything I can for speed, or at least at this 
point trying to figure out where it can be had.  There's another line 
of thought brewing which might involve source filters or similar dirty 
words, but I'll save this heresy for later.

--Eric
-- 
The only thing that could save UNIX at this late date would be a new $30
shareware version that runs on an unexpanded Commodore 64.
--Don Lancaster (1991)
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------