From: Donny V. <don...@gm...> - 2012-03-24 20:40:40
|
Reply to Neha and Ashish: On Sat, Mar 24, 2012 at 10:06 AM, Neha Narang <nar...@gm...> wrote: > Can you elaborate what you have implemented? On Sat, Mar 24, 2012 at 2:33 PM, Ashish Sharma <ash...@gm...> wrote: >> > I've got a SWIG module for GPSEE/Spidermonkey I've been working on. >> > Unfortunately when I was nearly finished with it I realized I wanted >> > to reimplement it based on a newer design I came up with. > > That's Great. Donny, do you have a repo available for your project? And > would you be interested to mentor the Javascript idea? I had a hard time learning how to do things "right" in SWIG even with the extensive documentation and the many modules implemented. Not all SWIG language modules seemed to agree on how exactly to do things. When I started work on my module, I decided that I wanted it to potentially become a good reference for other developers who wanted to work on SWIG modules. To that end my goals were to do as much work in the .swg runtime files as possible. I hoped it would be possible to one wrapper for various Javascript languages, with very few differences, and as many of those differences as possible be located in .swg runtime files. I hoped to eventually submit my GPSEE/Javascript language module to the SWIG community, and receive feedback on it so that I could bring it up to a standard that the community could agree would make it a good reference for future SWIG developers. One of my early mistakes was emitting "flat" wrappers that were not well prepared for C++ namespaces or static member variables. The consequence of this was that I decided to rewrite a good deal of the module. I can release the source code if anyone is interested, though I suppose part of the reason I have been hesitant is because SWIG development is mediated by Subversion, and I would rather use a DVCS like Mercurial or Git. My decision was to hold onto the module until it was sufficiently mature to ask the community for feedback. Another issue I'm unsure of is multiple inheritance in C++. Javascript developers typically use "duck typing" because Javascript's "prototypal inheritance" is not well suited for multiple inheritance. I believe the "instanceof" Javascript operator can never be made compatible with multiple inheritance. One potential work-around for this problem would be for class wrappers to add a static member function that would identify whether or not a Javascript object is an instance of the class. Another multiple inheritance challenge is respecting the Javascript language's ability to modify "prototype objects," which is analogous to making run-time changes to what in C++ parlance are called class members. These multiple inheritance challenges are perhaps esoteric and not important in any practical sense, however I am just the sort of person who would fret over the issue :) My module has been in development for a long time because I rarely have time for it. I still have little time for it, so I would probably be a poor mentor, though I'm not sure what the demands on a GSOC mentor's time can be like. I would be enthusiastic about having another developer to help in finishing this module. Neha: Are you interested in supporting a particular Javascript interpreter, or a particular Javascript application development platform? The distinction I make between the interpreter and the application development platform is a consequence of the evolution of the Javascript ecosystem. While Google is the principle author of V8, and Mozilla the principle author of Spidermonkey, both seem primarily interested in their web browsers. Neither seem to have taken the initiative to make it possible for Javascript programmers to "escape" from the web browser and develop other types of applications in Javascript. The community has created numerous projects in pursuit of this goal, however. My first target was the Spidermonkey interpreter and the GPSEE platform. I will try to attach my source code as an SVN diff to the mailing list tomorrow! -- http://codebad.com/ |