Expand plugins API to do conventional module-as-object handling

[GoogleCodeExporter]

For example:

import("sys.io")

should load the plugin sys/io.so and create (if necessary) the "sys" and
"io" objects.

This doesn't require replacing the current plugin API, just an expansion.
e.g. LoadModule("name"), which creates the objects and then calls
LoadModule("translated_name",targetObject), where targetObject would be the
last object in the module's name ("io" in the above example).

Original issue reported on code.google.com by sgbeal@googlemail.com on 7 Mar 2009 at 2:36

[GoogleCodeExporter]

Original comment by sgbeal@googlemail.com on 7 Mar 2009 at 11:18

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The current thinking on this is to instead do like:

http://jshq.org/commonjs/0.1/modules.html

however, i'm not satisfied with the way that model apparently pollutes the 
global 
namespace with an "exports" object.

The current include() implementation behaves as CommonJS require() specifies, 
except 
that it returns the result of the script, as opposed to poisoning a global 
variable. 
The CommonJS model can be done as-is in juice if the scripts are changed to 
something 
like:

exports.foo = function()
{
    ... client code ...
};
exports; /* acts as return value for include()*/

Original comment by sgbeal@googlemail.com on 13 Sep 2009 at 3:36

[GoogleCodeExporter]

i won't ever get around to doing these.

Original comment by sgbeal@googlemail.com on 18 Jul 2012 at 3:47

• Changed state: WontFix