On Wed, Mar 21, 2012 at 16:55, Brian LeRoux <[email protected]> wrote: > I don't mind this shed but I'm wondering what the purpose of > lib-platforms/blackberry/cordova part? > > why not just lib-platforms/blackberry/ ?? > > also, and again just touring around the shed, do we plan to ditch > lib-platforms for lib/platforms after the merge is complete?
Good questions. I'm not married to the current split, just seemed like the most consistent way of doing it, once I got around to writing the code. The reason for the unwieldy "lib-platforms/blackberry/cordova" bit is that, again, I can look at any file name and see what the actual module is, by look 'up' the path to the cordova part. But it seems a bit much. I think one thing that might make sense is to just drop 'cordova' everywhere in these trees. One thing I'd like to eventually do is to use "relative" module id's everywhere, and then in that case, you'd NEVER see a require() with a 'cordova' in it anyway (except for 'root' require()s), at least in our own modules. There's one minor hitch with that, and that is that we have a 'cordova' module, and then modules like 'cordova/builder'. To make this work today, the common tree needs a 'cordova' directory, along with a cordova.js sitting right next to that directory. Slightly weird. Node has a convention that says: if you're looking for module x/y/z, but can't find x/y/z.js, look for x/y/z/index.js. If we also adopted this (not difficult to implement), then we'd move the code in lib-common/cordova.js into lib-common/cordova/index.js. Then we can cleanly kill all the 'cordova' directories, because there won't be anything else IN those directories, but the cordova subdirectory. So, some thoughts, assuming removal of the 'cordova' directories, given the current lib-common/ lib-platforms/ lib-platforms/android/ lib-platforms/... lib-scripts/ 1) flatten to /lib: lib/common lib/platform/ lib/platform/android lib/platform/... lib/scripts 2) additional flattening of removing 'platform' lib/common lib/android lib/... lib/scripts ***** 2) seems like the best to me, as flat as we can get, but has one issue, in that our 'special' names (currently just 'common' and 'scripts') are in the same 'namespace' as platforms. Hope noone comes up with an OS called 'common' or 'scripts' :-) Prolly not a big problem. You can modify the script 'build/split-cordova.sh' to play with how things are split up. -- Patrick Mueller http://muellerware.org
