[haiku-development] Re: The Call for Scripting Languages: Lua
- From: Jack Small <jaxs@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 26 Sep 2009 15:53:28 -0700
Matt,
On Sep 26, 2009, at 12:08 PM, Matt Madia wrote:
On Fri, Sep 25, 2009 at 15:13, Rob Hoelz <rob@xxxxxxxxxxx> wrote:
I noticed the following question comes up pretty often in #haiku and
elsewhere:
"Does it have bindings for language X?"
So I'd like to try and combine a language I love (Lua) with Haiku and
see what comes out of it. However, I have a question or two before I
can begin.
Do you have any interest in utilizing SWIG to create those bindings?
http://swig.org/
I do but I see two major issues. First is that, while absolutely
fascinating design, the primary purpose is to add scripting to
existing C and C++ applications. Obviously it is also useful for the
other way, adding static bindings to a non-C language. However each
language would require it's own tools and you end up with an elegant,
thin, bridge.
Second, the one thing SWIG does not do is allow you to subclass C++
objects and overload functions in a dynamic runtime interpreter.
AFIK, there is no truly dynamic way of doing it with C++ because of
its inline runtime. If someone knows better I'd love to be wrong! So
far, every tutorial I've ever seen about writing BeOS/Haiku apps
begins with subclassing BApplication. Most of the GUI API assumes you
will subclass various views.
One of the proposed Google Summer of Code projects was to create
python binding using SWIG, quoting the project proposal:
What I want to do is to create a python binding by using SWIG, so my
efforts can be used in future to create additional bindings (like
perl, ruby, etc).
There are large gigantic parts of the Haiku API that would work fine
in SWIG and every other language could certainly model with your
example.
In this way we could uniform the bindings and makes the haiku API more
easy to learn. This will attract new developers and new users to
develop new applications.
The beauty of SWIG is that it preserves the existing API, producing
native results. I would be all for writing specialized subclasses
that could be used to bind a C API with native classes. If all the
non-C languages offer the same API then I agree it will drive
development a lot faster. I've done some testing and believe it can
probably be done with minimal interference.
Basically, while SWIG may take more effort up front, it will
accelerate future bindings for other languages.
I agree that this a major issue for new languages but as pointed out
in previous messages there is also the unique challenge of the
threading model on Haiku. Each language will have very different
design issues internally. Having a target API already established
means more time perfecting the threading issues. I am certainly
willing to help write and test it!
If there are existing bindings, I'd certainly be curious to see how
they solved this subclass issue.
More later,
Jack
Other related posts:
