removing include()
r...@tinyclouds.org
the global namespace. The current implementation looks like this:
http://github.com/ry/node/blob/4c51af882dfb4b32bff287575fbfd30f9a1d4bbb/src/node.js#L210-219
This is convenient for little scripts like unit tests, but it opens
the door for misuse. Libraries shouldn't ever use it since it will
pollute the global namespace.
CommonJS does not have such a method and consequentially necessitates
lots of boilerplate code like this:
var blah = require("blah");
var foo = blah.foo;
var bar = blah.bar;
I want to avoid this, but include() (at least in its present form) is
not the right way to solve it.
I will remove it. Unless there are some strong objections?
Connor Dunn
another (maybe something like
http://docs.jquery.com/Utilities/jQuery.extend), then you could do (I
think)
var blah = require("blah");
Connor
2009/10/5 <r...@tinyclouds.org>:
Hagen
Dissertations are a successful walk through a minefield -- summarizing them is not. - Roy Fielding
Ryan Dahl
> another (maybe something like
> http://docs.jquery.com/Utilities/jQuery.extend), then you could do (I
> think)
>
> var blah = require("blah");
> extend(process, blah);
I like it!
node.extend(process, require("/file.js"))
instead of
include("/file.js");
It's more verbose but leads to better namespacing. It reads okay too.
Ryan Dahl
> another (maybe something like
> http://docs.jquery.com/Utilities/jQuery.extend), then you could do (I
> think)
>
> var blah = require("blah");
> extend(process, blah);
This would also address Isaac's problem:
http://groups.google.com/group/nodejs/browse_thread/thread/187afe17c698578c
Ryan Dahl
node.mixin() with the same semantics as jQuery.extend() except if the
first argument is left out, then it uses "process".
E.G.:
node.mixin(require("/file.js")); /* was: include("/file.js"); */
/* Isaac's use case */
node.mixin(exports, require("/file.js"), require("/mjsunit.js"));
Tim Caswell
object. We probably should do it in the core since it breaks naive
code that loops over properties using an unprotected for .. in ..
statement. There is a lot we could do to add to the functionality of
the javascript if we had libraries that modified the core objects.
For example, we could add Object.prototype.mixin and then the syntax
would be:
process.mixin(require("/mylib.js");
and in a constructor definition we could do ruby style mixins by:
function MyConstructor() {
this.mixin(SomeModule.prototype)
}
Again, I'm not proposing adding this into node's core unless we want a
more powerful javascript out of the box at the cost of lost
compatibility. If it were my project I would do this because I often
favor power and ease of use over compatibility with legacy code. I'm
just trying to get a feel for the community's feel on this one.
Ryan Dahl
>
> I was wondering where we stand on modifying the prototype of built in
> object.
I'm against it. This is something that can be done in user code - I
think node would be overstepping it's scope if it did that. Even
require() is a bit out of the scope of node - which I'd like to only
focus on I/O - but is a necessity.
Jacob Rus
either the current local scope, or the particular file's global scope?
(or is there no such thing, and the only global is the truly global
'process'?)
I really like using include because it lets me avoid writing a ton of
lines to essentially "consider this other code file part of the
current one". To be honest, I don't think there are many use cases
for merging things with 'process' that wouldn't be as well or better
served by a 'put everything here in the current scope' tool.
Cheers,
Jacob
Ryan Dahl
>
> To be honest, I don't think there are many use cases
> for merging things with 'process' that wouldn't be as well or better
> served by a 'put everything here in the current scope' tool.
As far as I can see, it's not possible to create a function which
takes one object and merges it into the local scope.
Ryan Dahl
> either the current local scope, or the particular file's global scope?
node.mixin(require("/file.js"));
Tim Caswell
with my turtle.js meta-programming example, but it required some nasty
hacks that have to be done at the text level. So some function in
node would wrap the source code to a file in a with statement (with
the passed in object as the "with" scope) and then eval/execute it.
Michael Carter
Not any good ways at least. I found a similar solution when playing
with my turtle.js meta-programming example, but it required some nasty
hacks that have to be done at the text level. So some function in
node would wrap the source code to a file in a with statement (with
the passed in object as the "with" scope) and then eval/execute it.
In the js.io project we allow require to import stuff into the file-level scope by using some with statement trickery. There is a performance penalty, but its not nearly as bad as was noted previously on this list. Depending on how your wrap the with block in closures, you can speed it up signifigantly.
But it seems like a bad idea for node.js. To tell you the truth, I'm sort of with ryan in saying that require functionality is almost out of the scope of the node.js project -- the compile function and the node.fs functions are enough to build a module system on top of node.
Actually, I'm almost of the mind that node.js should just get it over with and start using the commonjs module system... it has some slightly different syntax, but its basically the same thing. I'm not exactly sure what the reasoning is for avoiding it.
-Michael Carter
Ryan Dahl
>
> But it seems like a bad idea for node.js. To tell you the truth, I'm sort of
> with ryan in saying that require functionality is almost out of the scope of
> the node.js project -- the compile function and the node.fs functions are
> enough to build a module system on top of node.
It would be nice to drop that weight. However, I find it would be a
terrible burden to load a module system at the beginning of each
script. (I suppose someone could wrap Node with a different script...
hmm. That might be something to try.)
> Actually, I'm almost of the mind that node.js should just get it over with
> and start using the commonjs module system... it has some slightly different
> syntax, but its basically the same thing. I'm not exactly sure what the
> reasoning is for avoiding it.
Yeah. I'm just not sold on their interface. I guess if people bother
me enough I'll adopt it.
Ryan Dahl
> scope by using some with statement trickery. There is a performance penalty,
> but its not nearly as bad as was noted previously on this list. Depending on
> how your wrap the with block in closures, you can speed it up signifigantly.
>
> But it seems like a bad idea for node.js. To tell you the truth, I'm sort of
> with ryan in saying that require functionality is almost out of the scope of
> the node.js project -- the compile function and the node.fs functions are
> enough to build a module system on top of node.
What if I provided a "node-core" executable which would provide all of
the C++ stuff, node.dlopen, node.fs.*, the event loop, etc but without
the module system. Basically leaving out src/*.js. Would you find this
useful to provide your own module system?