Simple modules decouples this concern from that of modularizing code; modules are not state-isolated, but share the same connected graph of module instances, including the "primordials" (Object, Array, etc).
Instead, module loaders (http://wiki.ecmascript.org/doku.php?id=strawman:module_loaders) are for creating separate instantiations of modules, again including primordials. The latter page is still a bit skeletal; I intend to flesh it out more in the next few weeks. But the idea is that module loaders allow you to create fresh, separated instances where you can control sharing, while at the same time keeping sharing as the default modus operandi. Dave Sent from my Samsung Captivate(tm) on AT&T Irakli Gozalishvili <rfo...@gmail.com> wrote: >Hi, > >I have noticed that [simple modules]( >http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules) don't >mention how does natives are supposed to behave across modules. Are they >shared or each module gets it's own Object, Function, Array, ... objects ? > >I think this is something that should be discussed / specified. Also some >popular libraries (prototype, sproutcore, extjs, fusejs) depend on extended >natives. FuseJS for example even uses iframe based sandboxing approach for >extending natives to avoid conflicts. > >IMO it would've be very nice if module had a different natives so that they >could extend those without any compatibility risks with other libs. Also in >that case would be nice to have convenient syntax for deciding whether or >not extension on natives are imported along with module. > >Regards >-- >Irakli Gozalishvili >Web: http://www.jeditoolkit.com/ >Address: 29 Rue Saint-Georges, 75009 Paris, France <http://goo.gl/maps/3CHu> > >_______________________________________________ >es-discuss mailing list >es-discuss@mozilla.org >https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
