Sterling Hughes <sterling@designmultimedia.com> writes:
> > 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?
Sorry for the vagueness, just trying to be very generic.
There are multiple ways of "automatically" getting information
about the interfaces library/module, some being:
- Generate the headers for the library from an IDL file,
that can later be used (directly or via a typelib)
for generating language bindings. (example XPCOM)
- Produce interface information as part of the compilation process.
(example .NET)
- Parse header files to determine the interface. (examples: SWIG,
most GTK+ bindings)
Once you have that information, you can:
- Compile an extension module for a particular language.
- Generate bindings on the fly using dynamic invocation
(XptCall, libffi, etc.)
In that space of possiiblities, I tend to favor avoiding
header parsing, and dynamic bindings rather than static
bindings.
Regards,
Owen
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