Re: GJS maintainership / November Bug Squash Month

[Andrea Giammarchi <andrea giammarchi gmail com>]

Hi Philip

On Fri, Nov 18, 2016 at 6:33 AM, <philip chimento gmail com> wrote:

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

this basically means for the next 5 years GJS won't be able to interact with modules published to npm

`require` is quite a simple feature to implement ... it doesn't have to be a full 1:1 nodejs port, it needs to resolve synchronously some folder/file and invoke the content via a closure.

This could be done on JS side too, I have the logic working in jsgtk already.

 

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? 

looking at examples I've seen here and there it's about exporting also `someThing` beside `some_thing` and since everything I've seen from GObject side is ASCII named, I don't think this should be a big deal.

However, object properties should also reflect camelCase and maybe the feature could be delivered behind a flag.

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

fun and cool was the ability to use ES6 right away (transpiled at runtime, not an option as it is for very big project) and require npm modules using same package manager everyone else in the JS ecosystem is using these days.

This plus the abilty to use camelCase and extend native classes in a ES6 fashion such `class MyButton extends Gtk.Button {}` ... instead of passing through the old MooTools style class approach.

Best Regards