require() implementation details
Wes Garland
I noticed something this morning while going over some GPSEE code.
Once upon a time, it was generally agreed that it was possible to implement require() either as a global symbol, or as a symbol which is local to the module.
Implemented as a local symbol, the require() function could theoretically be passed around to other functions, carrying along its authority. Additionally, in order to implement relative path loading, each instance of require() could have an internal symbol remembering the path of the module it is in, to use in compositing module filenames.
It seems to me adding the paths member to require(), with its current semantics, forces it to be a true global. I have thought about proxying all require.path instances to global.require.path, but I think this still leaves holes around operations like delete.
Thoughts? What are other implementors doing with require.paths? If you're using a global require, how are you keeping track of relative module filenames?
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Kris Kowal
> It seems to me adding the paths member to require(), with its current
> semantics, forces it to be a true global. I have thought about proxying
> all require.path instances to global.require.path, but I think this still
> leaves holes around operations like delete.
The bit about require.paths is very carefully worded to permit it to
be object identical to a global require paths array. The spec is
clear that any modification has to be done in-place with the given
object, using methods like splice, since re-assignment may have no
effect. This is what we do in Narwhal. I can readily see why it
would not be desirable to have require.paths exist at all in some
cases though, which we also leave as an option. We might have to
revisit the idea of require.paths someday, but I think we're fine for
now. We might want to move "require" properties into the "system"
module, for example.
Kris Kowal
Ash Berlin
On 11 Feb 2010, at 16:45, Wes Garland wrote:
>
>
> Thoughts? What are other implementors doing with require.paths? If you're using a global require, how are you keeping track of relative module filenames?
Hippo has a require per module, but the require.paths is dont-delete, read-only meaning all instances share the same array of paths that you can only change with push/pop etc.
Wes Garland
Thanks for calling this out -- it is indeed a key piece of spec that I overlooked --
The spec is
clear that any modification has to be done in-place with the given
object, using methods like splice, since re-assignment may have no
effect.
Ash - thanks for follow-up, that sounds like what I will implement. GPSEE currently has a unique path per require, which is clearly wrong.
Wes
Attila Szegedi
> Thoughts? What are other implementors doing with require.paths? If you're using a global require, how are you keeping track of relative module filenames?
I resolve the identifier "module" against the top-level scope in the scope chain of the current require() invocation, then if it's an object, retrieve the property "id" from it; that gives me the absolute ID of the module. If this fails for whatever reason (identifier does not resolve to an object, object has no property of that name) then require() with relative ID fails.
It can't fail for a module also loaded with require() though as it'll make sure there's a readonly-dontdelete "module" object with a likewise readonly-dontdelete "id" property.
Attila.
Ondřej Žára
>Hippo has a require per module, but the require.paths is dont-delete, read-only meaning all instances share the same array of paths that you can only change with push/pop etc.
>
> Thoughts? What are other implementors doing with require.paths? If you're using a global require, how are you keeping track of relative module filenames?
And this is basically how require and require.paths work in v8cgi :)
O.
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.