Unfortunately I'm not as good as C/C++ as I am with JS so I don't think I can help much but thanks for your effort.
>
or suggest a feature that you've long wanted to have in GJS
As JS developer since year 2000, I'd like to take this opportunity to write down my wish list for GJS:
- either CommonJS require or ES6 import, anything better than current way to import files or export modules
I'm planning to continue porting forward to subsequent versions of SpiderMonkey until we have ES6 modules. (They seem to be nearly finished.) I wouldn't spend time rewriting the module system only to have it replaced by ES6 modules later on...
- a camelCase environment like every single other in JS. If I've managed in jsgtk to do this on top of GJS I guess it'd be straight forward to have it in core (here I could maybe help if the transformation is done on JS side)
Yes, my opinion is this should have been done from the beginning; it's strange that it works for properties but not for methods. I support this but only if it turns out we can do it without breaking existing code and without imposing a performance burden. I would probably not do the transformation on the JS side for performance reasons. If I were able to find out the C++ code where it would need to be done, and outline an approach, would that make it comfortable enough for you to work on it?
If these two things were in I am pretty sure many developers would be interested in porting some of their modules to GJS too. Right now it's simply unthinkable to integrate anything existing for the nodejs env into GJS, unless you use jsgtk, but I'd rather kill jsgtk unofficial wrapper and have what I think made it fun and cool to develop with in GJS.
I have some vague ideas about this that need fleshing out. What from jsgtk do you consider made it the most fun and cool? It would be good to know where we could make the most gains first.
Philip
