On Wed, Dec 9, 2015 at 3:47 AM, <philip.chime...@gmail.com> wrote: > > > Nonetheless, I'd recommend parsing the GIR even over listing the file > names. It's all the info you need in one file, it's already present on your > system, and you wouldn't have to do such things like "catch > (probablyAProperty)" because the GIR is always unambiguous. >
right now I'm jhbuilding 160 repository to be able to try and build whatever Giovanni did before but if these gir files are included in each repository I surely prefer parsing them. Beside, there are methods like `GLib.test_add_data_func_full` found in the gjs-documentation repo that break if used so I'll need to do some runtime GJS sanity check before deciding what to do. The probablyAProperty thing is to create accessors instead of methods where accessors cannot be retrieved as default value through the prototype and funny enough cannot be retrieved at all or they will fail ( 'prop' in GTKConstructor.prototype fails and Object.getOwnPropertyDescriptor(GTKConstructor.prototype, 'prop') too ) The generated file is big in size and requires more RAM (hence my decision to not include it by default) but performance wise it doesn't compromise much. It's an indirection and since I don't even know how many people would like to have the whole namespace camelCase I thought this was the best way to explore the interest. For greppability and comparison with PyGTK where I could find many more examples, developers (me included) might find just OK to use the C/Pythonic underscore_case and move on creating apps instead of bothering with camelCase. Let's see. P.S. I do need documentation but it would be an insane nonsense to create a file like this manually https://github.com/WebReflection/jsgtk/blob/master/jsgtk/gi.js
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
