RE: [Wxruby-dev] Cable ties

[Curt Hibbs]

repeater wrote:
> curt wrote:
> > If you are interested in joining the project, perhaps you would be
> > interested in checking out Cable to see if we can use it in
> place of SWIG.
>
> hmm this is interesting. i'd like to test it out, but at first sight it
> seems to be only supporting tcl right now.

A ruby emitter would need to be created, so the question is how
easy/difficult does this appear to be, and the next question would be
whether the payoff would be worth the effort.

The problem with SWIG is that it isn't sophisticated enough about processing
C++ header files, so it becomes necessary to write interface files, and
these interface files require ongoing maintenance to stay in sync with the
underlying C++ source code. This is probably an acceptable "evil" if there
is no other choice. However being able to process C++ header files directly
(without the need to interface files) would be preferable.

I'm trying to take a long-term view here. I'm (slightly) more concerned
about the long-term maintenance costs than the initial development costs.

> i suggest our modus operandi with Cable:
> a) wait until perl/python hordes releases a binding. there are
> many more of
> them, and the path to ruby is better from there, so we can easily create a
> binding based on their attempts. (better than being the 2nd non-tcl
> interpreted lang)
> b) as the p-language bindings realize, and if Cable is as amazing as they
> claim, surely some projects will start to utilize it. it is best to make a
> judgement call about the amount of effort and functionality needed by
> looking at a working large example.
>
> i'd consider the Cable route a wait-and-see don't you think.
> overdepending right now could damage the progress of the swig route.

I think we would probably pick one route (SWIG or Cable) and stick with it.
I wouldn't see us changing later on.

> and about the swig sentiment, the main critique seems to be too much
> micro-management, but i think if we are clever we could avoid it in this
> project. but ho! the best way to regain my sanity, is to dive
> into swig-land
> a bit and see for myself

Sure, I just want to avoid, if possible, being in the position of having to
manually synchronize a bunch of interface files with a large set of C++
header files. I initially tried to use SWIG without interface files
(theoretically possible) but gave up because SWIG couldn't properly parse
all of wxWinbdow's C++ header files.

Curt