Interfaces to foreign libraries have been traditionally called bindings or wrappers. I never cared too much about eventual differences in meaning, I used to use them as synonims; now I'm beginning to realize that they have different meaning.
Let's speak in Eiffel or C/C++: a
WRAPPER is a tiny reference (i.e. unexpanded) object containing a pointer to the unde lying data structure, think about it as a glorified REFERENCE[POINTER]; a binding - in my humble opinion - shall be a way to directly use the actual data structure as an Eiffel object, turning that pointer into the actual reference used on the Eiffel side.
Needless to say this double layer -
WRAPPER and wrappee, referred thorught "feature handle: POINTER" pratically means to manually manage memory inside each effective wrapper coupling it with deferred classes that implements memory policies like
EIFFEL_OWNED,
C_OWNED,
GLOBALLY_CACHED,
MIXED_MEMORY_HANDLING, or
REFERENCE_COUNTED.
This is how wrapping has always been done in Eiffel, either in Eiffel (in EWLC or EWG) or with C glue code (elj).
To bootstrap Liberty we still need them and we will still need them a lot after Liberty will be ready.
My proposal is to allow better integration with foreign languages or object-models, like C-with-
Gobject or C++.
Surely both models do not perfectly map Eiffel's object way; we still will need to instruct Liberty on how to handle those datatypes generated by foreign code,
SmartEiffe started to develop
external types, something that eventually bring us "real bindings".
We need "only" to allow the developer of a binding to provide
object_size, generator and generator_type.
Those will be interfaced the object-model facility of the foreign language, for example with
C++ Run Time Type Identification, the C++ typeid operator and its
std:type_info object; Gobject also offers a comfortable
type system that will fit.
Obviously there will be mismatches, peculiarities and headaches but it can be done. Other languages have done it, we can also.
There will a cost. The cost is "diverging" farther from ECMA; I read the standard a couple of months ago and I wasn't satistied by what I read about integration with other languages. I had the impression they don't care that much about integration. What I found there was a language that already diverged from what we learned to love as Eiffel.
We standed still, they walked away. We shall find and walk our trail. Perhaps different, perhaps useful for a later merge.
Let's keep writing wrappers and not binding to bootstrap.
