On 12 Aug 2001, Owen Taylor wrote:
>
> Rasmus Lerdorf <rasmus@php.net> writes:
>
> > > By introducing another layer of abstraction we will most probably decrease
> > > the performance of all languages[1]. That is, since the universal
> > > interface to, given your example, the Sablotron XSLT library is the API
> > > and Perl, Python and PHP have internals different enough that there would
> > > have to be a certain amount of glue and translation work between the
> > > structures of the extension layer and the internals of the interpretter.
> >
> > It should still be possible to come up with some guidelines for writing a
> > single extension that supports multiple scripting languages. Especially
> > for something like Sablotron which isn't that complex. You feed it some
> > XML and some XSL and it spits back a result. Most of the work in writing
> > the extension is figuring out how the user-visible API should look and
> > then translating that API along with its function/method calls and
> > argument type mangling to whatever the thing that is being glued is
> > expecting.
> >
> > Note that I am not talking about runtime binary compatibility here. I am
> > talking about source compatibility where potentially big chunks of code
> > would be very different across the different languages. In an approach
> > like this I don't see a performance issue. It is more of an education
> > issue actually.
> >
> > And with a bit of effort I bet we could come up with enough common ground,
> > or at least some nifty macro tricks, where people wouldn't feel
> > overwhelmed by the task of supporting multiple scripting languages when
> > they sat down to write some new backend library.
>
> I think knowledge of the rules for writing bindable libraries is
> much more useful than macro tricks.
>
> Writing down the rules would be a big project, though the set
> of rules isn't that big. A few important ones are:
>
> - User data stored with a structure should have an associated
> notifier.
>
> - Callback functions must take not just a function, but
> a function,user data, destroy notifier combination.
>
> - Data structures should be one of:
>
> * Immutable and refcounted.
> * Copy by value.
> * Copy by reference, reference counted, with destroy
> notification and a user data facility for maintaining
> persistant language <=> library associates.
>
> - Keep the C simple. Opaque structure with accessors is
> the ideal, structures initialized with magic macros
> one of the worse offendors.
>
Yes! Yes! Yes!
Its surprising how many library authors seem to ignore this.
> Etc. If you follow these rules, you get a a library where writing
> bindings for it is a brain-dead task. But still task. A library like
> GObject that standardizes memory management, and object-oriented
> structures helps quite a bit, but I'm certainly of the opinion that
> the eventual goal has to be
>
> - write a library using tools that produce an introspectable
> descriptions of its interfaces.
>
> - Language bindings are automatic and can be done without
> a compilation step.
Not quite sure I understand you here -- write a library using tools
that produce an introspectable descriptions of its interface???
context?
Are you talking about a library that is written so that it can be
analyzed by a program and then extension bindings for the individual
language can be created?
-Sterling
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4