[7:49]<eddyb> assuming someone will be able to reply... [7:54]<eddyb> should require load the first file that matches{.,/usr/lib/myJS/modules/,...}/$NAME.{js,so} in case the extension is not provided and {.,/usr/lib/myJS/modules/,...}/$NAME in case the extension is provided? [9:15]<ondras> eddyb: first, extension should not be provided [9:16]<ondras> second, only modules identified by a starting dot are searched relatively to current module's path [9:18]<ondras> so you never search both . and /usr/lib/myJS/modules/ [9:19]<ondras> http://wiki.commonjs.org/wiki/Modules/1.1#Module_Identifiers [9:50]<eddyb> okey, makes sense [9:51]<eddyb> that makes it impossible to have a .so module and a .js one with the same name, right? [10:40]<ondras> eddyb: actually, some implementations use modules which have a .js and .so parts [10:40]<ondras> we call them "blended" or "hybrid" modules [10:40]<ondras> although the specification does not touch them, it is a common practice for such module to first load the .so part and then apply the .js using the same exports [10:41]<ondras> eddyb: ^ [10:41]<ondras> but you are very correct that there cannot be two *different* modules with same name and varying extensions [10:49]<eddyb> I was thinking about doing hybrid modules by allowing the js part to call require for the so part and then add extra stuff to the exports. also, calling require("myModule") would result in loading myModule.js or myModule.so, if myModule.js doesn't exist [10:53]<ondras> this really is not specified [10:53]<ondras> but you should keep in mind that native modules might not always have the .so extension [10:53]<ondras> think dll or dylib [10:53]<ondras> so it might be best to implement hybrid logic at the embedding layer [10:53]<ondras> as far as i know, gpsee and v8cgi do this. [10:54]<eddyb> ok, going to have a look into them [16:21]<Dantman> has commonjs actually progressed anywhere since I stopped looking at the list? [16:24]<Wes-> Dantman: yes [16:25]<Wes-> we painted all the bike sheds blue [16:25]<Wes-> now we're just working on the shade [16:26]<Dantman> heh... [18:08]<eddyb> would be nice if an "extend" method would be standardized... [18:09]<eddyb> it could be useful for stuff like extend(require("Io"));... [18:11]<eddyb> if Io would have a constructor function class File, then one could just do new File("test.txt", File.readOnly) :D