[haiku-development] Re: The Call for Scripting Languages: Lua
- From: Donn Cave <donn@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 26 Sep 2009 21:32:58 -0700 (PDT)
Quoth Jack Small <jaxs@xxxxxxxx>,
...
> 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.
Yes, that's sure an essential part of the API. My Python Be API library
(Bethon) does it in a reasonably idiomatic way, so the code for a Python
application looks approximately like it would in C++, if you squint hard.
I suppose in theory Swig could do that, if they're willing to work with
internal implementation features of Python that are not supported in terms
of backwards compatibility or anything.
Much harder to adapt the API to a language that doesn't resemble C++
so much. I've tried it with Objective CAML, which does have an OOP
model but doesn't support optional parameters, and I'd really like
to work something out for Haskell but have no idea yet how it would
work.
When I started working on it, I was still using my BeBox - just to
relate this to a time frame - and I'm sure Swig has advanced a lot
in the intervening years. One of my objectives was to support each
API class in a separate module, so for example you don't have to map
in a giant Python library module that has all the code for every BView
subclass etc., just to get the BEntry class. Maybe these days that
memory footprint isn't so important, but anyway I felt that even if
I could have used Swig, it would have added so much overhead that
I couldn't have afforded to separate the modules. In the end I probably
didn't give it a fair shake, but it just looked like a rathole to me
and I decided not to go any further.
What I would really like for non-C++ bindings, is a complete and
machine readable specification for the API. The .h files are a
beginning, and of course machine readable if you care to put in
the effort, but they only address C++ language features. For many
other language bindings, you have to know which are input parameters
and which are output, you have to know more details about memory
allocation, etc. You might need to know even more for some languages -
I think Java would need to know the set of possible exceptions?
Everyone who ports the API to a new language will otherwise need
to work that out, function by function. And I think C++ programmers
could benefit, viewing it as minimal but rigorous documentation.
If Swig development produces a specification like that, that's cool.
If it just substitutes for one, assuming that every language will
then use Swig, then I think that's misconceived.
Donn Cave, donn@xxxxxxxxxxx
Other related posts:
