Re: [FreeWRL-develop] Codebase port to c++?

[doug s. <hig...@ho...>]

> >>
> >> Hey all, so spidermonkey-17 is released, which is going to be the last
> >> spidermonkey that has a C API; after this it's C++ only.
> >>
> >> Should we port freewrl to C++ or freeze our compatibility to
> >> spidermonkey-1.5 through 17 ?
> >>
> > 
> > What do you think Ian? Would you like to keep upgrading or would you
> > prefer a freeze?
> > -Doug
> > The last time the freewrl C vs C++ issue came up, C won.
> > I had done a test where I got freewrl to compile as C++. But then it was
> > just C code that took longer to compile on my slow old machine, and had
> > some awkward areas that would need a rewrite. We do have some C++
> > at-the-margin: libs and plugins.
> > I think there are ways to wrap a C++ library with a C interface, if
> > necessary. But that could be more work for the main javascript
> > maintainer - that's been you Ian - with unknown gain in functionality.
> > My guess: freeze.
> > 
> 
> Freeze is easier, since we don't have to port. However, not keeping up
> means we end up relying on dead code--or worse, embedding dead
> code--which in general isn't very nice to do.
> 
> It's going to be a -long time- before the next spidermonkey is released
> (next release is v24, which will be 2014 I think they said), but I
> thought it'd be worthwhile to bring it up.
> 
> Also, migration to C++ may have other benefits -- for instance, it might
> open us up to more contributors or more users of the API. Going through
> the whole codebase and converting our objects/structs/etc to classes
> would probably allow us to simplify the code quite a bit too, at least
> in theory....
 
the gglobal() thing comes to mind. It's 1:1 with 'browser' as seen by SAI, so instead of looking it up by thead it could be passed back to the SAI client in the opaque browser pointer, and passed back in on SAI calls.
. 
web3d.org specs show abstract base classes to nodes. It might help programmers if we were following it more closely.
> 
> I think if we were to do this change, this would put us into FreeWRL-3.
> 
Might need a fork until it was stable and proven? If it broke too many things it might lose developers -all their hard work destroyed, demoralizing us. So it might depend how well it was refactored. If you've ever read books on agile programming or eXtreme programming they talk about unit tests being run after each refactoring step, so they can roll back if they break something.
 
We don't have an automated test suite. So perhaps that could/should be a first step. 
 
But even then, 
Q1. how to set up unit testing to test all the platforms including smartphones and tablets, and 64bit, from any one single platform, in a fast, convenient feedback way?
Q2. And how to do unit testing on computer graphics, with input devices and rendered output, and multiple frames and events involved?