RE: [Wxruby-dev] Cable ties

[repeater]

curt replied:
<..>
> 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.

a wise consideration, it seems like a full time job (ask lyle ;-)

firstly i do not think that the wxWindows components themselves would change
often or be crucial (e.g adding important things to wxButton would be
unlikely). so our basic collection of components is basically complete

i think more wxWindows components would be released though, and those will
have to be added manually.
but consider this, if we can take wxRuby to a point where it mirrors
wxPython to a certain extent, we can link it with the project and update as
it updates. the feeling of "chasing" is reduced dramatically, leaving just a
bit of easy conversion and ruby c api application.

you can even get a semi-automated conversion app going, i say with the aid
of hand waving ;-)

i think that following wxPython would be very wise, especially since it
seems at inspection to have well considered original material (little
platform specific things, handy wxPyXXXX class derivations) that we wouldn't
get from Cable

>
> > 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.

perhaps, if we had to write SWIG from scratch, but i think we've got a
pretty ok thing going already.
i recommend we go on with swig a bit, see how much effort it turns out to
require and go from there.

regards
Peter