Hm, not sure:
> Recall, that if the symbol is visible in the global namespace, the only
> possible way to make it not visible from within a module is to purposefully
> collide it.
>
1) if I execute the module in separate context, _nothing_ from global
namespace would be visible within a module;
> The idea here is that the object allows us to extend the functionality
> later, whereas if we don't, then to add more function we'd need to add MORE
> globals
Not necessary. All "require" related functionality can by properties
of the "require" function *object*. That is a handy feature in
JavaScript that all functions are objects and can have properties.
> (require_path, get_modules_loaded(), etc), or we'd need to add more
> functions to the require function (shiver).
Why shiver?
require.loaded
require.path
Looks great to me.
Peter
>
>>
>> I don't think so, at the very least if you want to work with relative
>> paths. The require function needs to know what module it's being
>> called from in order to correctly resolve relative paths.
>>
>
> In v8cgi, I solve this by performing a chdir() every time "include" is
> called. So, I move the execution to the directory which contains file
> being loaded and this ensures relative paths work as expected.
>
>
> What is your opinion?
>
>
> O.
I think it suffers from the same problem as my original stack-based
approach? For example:
main.js:
include("foo/bar.js");
bar();
lib/bar.js:
function bar() {
include("qwerty.js");
}
lib/qwerty.js:
throw "ok!"
I just executing main.js in v8cgi, and it failed to find "qwerty.js".
If you move 'include("qwerty.js")' to outside the function it will work.
This is the problem I had with the previous version of Jack's
"require", and I couldn't think of a way to fix it without some sort
of macro or exception throwing/stack trace craziness. But the new
solution seems to work great.
It wraps the code in a function, but if you don't want that extra
scope you could use a "with" statement instead.
(also, chdir-ing might cause issues with File and relative paths)
Anyway, regarding the "require" pollution, isn't the whole point of
this module system that you can workaround namespace conflicts? I have
no problem with declaring "require" to be a reserved identifier in
this system, along with "File", etc.
-Tom
> Anyway, regarding the "require" pollution, isn't the whole point of
> this module system that you can workaround namespace conflicts? I have
> no problem with declaring "require" to be a reserved identifier in
> this system, along with "File", etc.
File does not need to be reserved in the same sense as require.
Require would always be present. File would only be present if the
File module is required.
Peter
I think File is a fundamental enough object that it should be
available by default, like XMLHttpRequest. This is how it is in Ruby,
Python, etc.
But we can save this debate for later...
-Tom
That would be a fine extension for a particular implementation. It
does not need to be standard, however.
Peter
This is just another one of these 20th century biases I'm stuck with.
I don't have any problem at thinking about objects with properties
that happen to be functions, but there's always something just a
little odd about functions that have additional properties. NOT THAT
THERE'S ANYTHING WRONG WITH IT. Just, a little unexpected.