GNOME Bugzilla – Bug 612226
[gjs] Add a sys module
Last modified: 2016-11-29 05:07:49 UTC
We should add a sys module modeled after python which contains the follow members: * argv -> as ARGV but with the whole C argv array * executable -> '/usr/bin/gjs' * exit(code) * path -> array, same as imports.searchPath * prefix -> --prefix option passed in to configure * modules -> listing all currently loaded modules in a key->module object * version -> '0.5' * version_info -> [0, 5, 0, 0] - includes major, minor, micro, patchlevel or so Should be pretty easy to implement all of the above.
I think it's more logical to put path and modules on the "imports" object. But the rest makes sense. version_info should be versionInfo
See http://wiki.commonjs.org/wiki/System IMO we should try to keep some compatibility with CommonJS where it makes sense.
path/modules could stay on the imports object, however it basically prevents these two to be used as module names. Perhaps imports.__path__ and imports.__modules__. We're not very compatible with CommonJS. Would make more sense to create a separate module or so which updates creates wrappers on top of our apis if we ever find the need to run any code written specifically for CommonJS. Does it exist anything of importance at all?
For the last year gjs has grown a lot of really ad-hoc API, and I'd just like to have a better distinction between things we consider "core" versus random stuff exposed publicly (like say console.c). Following CommonJS precedent allows us to benefit from at least some ostensible API design and discussion that other people working on non-browser JavaScript systems have come up with. For us of course, the GNOME stack covers a vast swath of things they need like I/O, etc. But there are some things not covered, and your proposed "sys" module is one of them. All I'm saying in the end is, if to follow their lead the only thing we need to do is call it "system" instead of "sys", wouldn't that make sense to do?
We have a 'system' module now with exit() and a few other goodies. The ES module loading proposal, not yet standardized, includes a System object as well. I'd be reluctant to strike further out on our own at this point. I'll close this for now, let's consider new additions to the 'system' module in separate bugs as they come up.