Proposed Node v2 API Specification Draft

149 views
Skip to first unread message

Olly

unread,
Jun 28, 2010, 5:46:54 PM6/28/10
to nodejs
Below is a revised API. Its still very primitive so i will be updating
it. I have yet to fill out all the arguments yet. but im working on
it.

GLOBAL

require([path])
require.paths

CONSOLE

console.log()
console.write()
console.debug()

NODE

node [extends process]
node.version()
node.uptime()

CLASS

class [class]
class.extend([object])
class.prototype.events [instanceof node.events]

EVENTS

events.emitter [class]
events.emitter.prototype.bind([event], [callback], [context=[emitter
object]])
events.emitter.prototype.emit([event], [arg1], [arg2], ...)
events.emitter.prototype.unbind([event], [callback])
events.emitter.prototype.reset([event])

PROCESS

process [extends node.object]
process.prototype.id()
process.prototype.kill()
process.prototype.memory()
process.prototype.cpu()
process.prototype.events.exit() [event]
process.prototype.events.stdin([data]) [event]
process.prototype.events.stdout([message]) [event]
process.prototype.events.stderr() [event]

NET

net.buffer [extends class]

net.dns.resolve([url], [type], [async=false], [callback=null])
net.dns.reverse([adress], [async=false], [callback=null])

net.stream([encoding="utf8"]) [extends class][abstract]
net.stream.prototype.readable [bool=false][readonly]
net.stream.prototype.writable [bool=false][readonly]
net.stream.prototype.open [bool=false][readonly]
net.stream.prototype.encoding [string="utf8"][readonly]
net.stream.prototype.buffer [net.buffer][readonly]
net.stream.prototype.autoflush [bool=true]
net.stream.prototype.delay [bool=true]
net.stream.prototype.timeout [int=0]
net.stream.prototype.events.open() [event]
net.stream.prototype.events.end() [event]
net.stream.prototype.events.close() [event]
net.stream.prototype.events.data([data]) [event]
net.stream.prototype.events.error([error]) [event]
net.stream.prototype.events.ready() [event]
net.stream.prototype.end()
net.stream.prototype.close([flush=false])
net.stream.prototype.flush()
net.stream.prototype.write([data], [encoding="utf8"])
net.stream.prototype.pause()
net.stream.prototype.resume()

net.socket [extends class][abstract]
net.socket.prototype.protocol [string="tcp"][readonly]
net.socket.prototype.port [int][readonly]
net.socket.prototype.address [string][readonly]
net.socket.prototype.bind([port], [address])
net.socket.prototype.listen([callback])
net.socket.prototype.close()
net.socket.prototype.dispose()

net.socket.tcp [extends net.socket]
net.socket.tcp.stream [extends net.stream]

net.socket.udp [extends net.socket]
net.socket.udp.stream [extends net.stream]

HTTP

http.server [extends net.socket.tcp]
http.request [extends net.socket.tcp.stream]
http.response [extends net.socket.tcp.stream]

... ill add the class structures to these when i can think them
through

URL

// http://en.wikipedia.org/wiki/URI_scheme#Examples
url.scheme([uri])
url.userinfo([uri])
url.authority([uri])
url.hostname([uri])
url.port([uri])
url.authority([uri])
url.path([uri])
url.query([uri], [parse=false])
url.fragment([uri])

CRYPTO

// Im sure this can be done more efficiently
crypto.hash [extends node.object]
crypto.hmac [extends node.object]
crypto.cipher [extends node.object]
crypto.decipher [extends node.object]
crypto.signature [extends node.object]
crypto.verifier [extends node.object]

IO

// All these methods are pretty much the same as before except the
argument list is appended with [async=false], [callback=undefined]
// Again would favour OOP, but no thanks to v8's GC

io.file.open()
io.file.read()
... etc

io.path.segment()
io.path.filename()
io.path.extension()
io.path.dirname()
... etc

io.link.destination()
io.link.follow()
io.link.create()
... etc

Mikeal Rogers

unread,
Jun 28, 2010, 6:08:57 PM6/28/10
to nod...@googlegroups.com
class? really?


--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.


Olly

unread,
Jun 28, 2010, 6:29:34 PM6/28/10
to nodejs

Olly

unread,
Jun 28, 2010, 6:30:49 PM6/28/10
to nodejs
An example of using the http server: https://gist.github.com/21c4d53ec77e7862232c

Olly

unread,
Jun 28, 2010, 6:42:17 PM6/28/10
to nodejs

Isaac Schlueter

unread,
Jun 28, 2010, 6:49:13 PM6/28/10
to nod...@googlegroups.com
What's the point of this exercise exactly?
Doesn't node already have api docs?

Mikeal Rogers

unread,
Jun 28, 2010, 6:57:58 PM6/28/10
to nod...@googlegroups.com
Is this a proposal for a new API?

Is this something Ryan solicited from the community when I wasn't around?

On Mon, Jun 28, 2010 at 3:49 PM, Isaac Schlueter <i...@izs.me> wrote:
What's the point of this exercise exactly?
Doesn't node already have api docs?
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

Olly

unread,
Jun 28, 2010, 7:10:23 PM6/28/10
to nodejs
no, not at all, this is something 100% unofficial.
Its a change im proposing.

Dean Landolt

unread,
Jun 28, 2010, 7:11:14 PM6/28/10
to nod...@googlegroups.com


On Mon, Jun 28, 2010 at 6:08 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
class? really?

Umm, class? Yeah, that's still reserved the last time I checked.

Micheil Smith

unread,
Jun 28, 2010, 7:16:33 PM6/28/10
to nod...@googlegroups.com
>> On Mon, Jun 28, 2010 at 6:08 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
>> class? really?
>
> On 29/06/2010, at 9:11 AM, Dean Landolt wrote:
> Umm, class? Yeah, that's still reserved the last time I checked.

Yeah, still reserved, as it's a Java keyword or something, but then again, require is reserved as well.

Olly

unread,
Jun 28, 2010, 7:27:38 PM6/28/10
to nodejs
var class = require('class');

exports.module = new class({ ... });

or something like that (similar to class.js).

On Jun 29, 12:11 am, Dean Landolt <d...@deanlandolt.com> wrote:

Dean Landolt

unread,
Jun 28, 2010, 7:34:31 PM6/28/10
to nod...@googlegroups.com
Require is not reserved, but class is and blows up in rhino. Yeah, yeah, "but this isn't rhino" you say? I know, but this could introduce pain for interop for no gain and it violates the letter of ES5 (though they did loosen up on that ridiculous list of reserved words: we can now legally use them as attributes without needing bracket notion).

Mikeal Rogers

unread,
Jun 28, 2010, 7:42:29 PM6/28/10
to nod...@googlegroups.com
The thing is, unless our BDFL weighs in on this it's not worth anyones time to try and bike shed this proposal. 

I appreciate a good discussion about API as much as anyone but this is a very large change and represents a lot of time from everyone that gets involved in this discussion and there is absolutely no reason to think any of it will end up being used yet.

-Mikeal

Ryan Gahl

unread,
Jun 28, 2010, 7:48:12 PM6/28/10
to nod...@googlegroups.com

On Mon, Jun 28, 2010 at 6:42 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
I appreciate a good discussion about API as much as anyone but this is a very large change and represents a lot of time from everyone that gets involved in this discussion and there is absolutely no reason to think any of it will end up being used yet.

+1, and why beyond this I'm not getting involved. Way too early to be trying to fix stuff that isn't broken.

r...@tinyclouds.org

unread,
Jun 28, 2010, 8:19:10 PM6/28/10
to nod...@googlegroups.com
On Mon, Jun 28, 2010 at 4:42 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
> The thing is, unless our BDFL weighs in on this it's not worth anyones time
> to try and bike shed this proposal.
> I appreciate a good discussion about API as much as anyone but this is a
> very large change and represents a lot of time from everyone that gets
> involved in this discussion and there is absolutely no reason to think any
> of it will end up being used yet.

I asked Olly to post it to the list for some good ol' fashioned bike
shedding. As I told him, Node has a lot of API warts and I appreciate
the effort - and that thinking about how API should be is helpful -
but that the project is not in a position to consider large API
changes now without reason - so I won't spend the time to go through
the proposal and comment.

Olly

unread,
Jun 28, 2010, 8:30:19 PM6/28/10
to nodejs
All i did was take the current API, split it into relevant namespaces,
remove the ambiguous use of camel casing, introduced consistency, and
enhanced some of the APIs. I was coming at this from a developers
point of view, if i was developing an application with node.js, how
would i want my api. A lot of the main structure is left unchanged,
its just a bit of a clean up.

The NodeV1 API is stabilising and ryan may soon soon be releasing an
RC with a feature freeze and be looking towards planning out certain
milestones for the next major version release. Which typically be re-
factoring a lot of the code, and re-stitching the patch-work API
caused by the initial feature bloat. I may be slightly jumping the gun
here but all i was looking for was some feedback for the future.

Bradley Meck

unread,
Jun 28, 2010, 9:09:15 PM6/28/10
to nodejs
The overall changes seem fine to me except for a couple of points. The
class namespace and the use of prototype so thoroughly.

For one, having class in the standard library makes it appear to most
developers that this is the way JS is commonly developed, when it is
quite often not the case (not to mention problems with prototype vs
classical). For the most part attempting to create classical
inheritance in JS ends up with convolution on an object due to needing
multiple "private" variables in order to allow virtual functions etc.
to be emulated when they should be private (kept inside of a closure).
I am not against it changing the instanceof operator but for the most
part, classical inheritance beyond setting the prototype of a function
creates confusion in JS due to the inability to recreate expected
inheritance 100%.

Secondly, the use of prototype can be quite a hindrance unless you
always use inheritance to extend objects. IE. EventEmitter.call({})
wont apply the prototype to {}, how many extends would you need for
each class you create? One for every interface it uses rather than a
function call. I feel that only Types should use the new operator and
even then I am not fond of 'new' due to the chaos it can cause with
the 'this' keyword being rebound for functions tied to an instance
(lord knows how much i use .call({},...)). With those finding a fix, I
rather like this being organized and having consistent naming.

Mikeal Rogers

unread,
Jun 28, 2010, 9:27:21 PM6/28/10
to nod...@googlegroups.com
-1 on request.response

This looks simpler at first but it's actually just more typing always. If you don't care about the response object it's just :

function (request) { ... }

When you do care about response it's now 7 extra characters every time you reference it rather than 7 characters at the top of the function.

-Mikeal

On Mon, Jun 28, 2010 at 3:30 PM, Olly <oliver...@kohark.com> wrote:
An example of using the http server: https://gist.github.com/21c4d53ec77e7862232c

tjholowaychuk

unread,
Jun 29, 2010, 12:45:28 AM6/29/10
to nodejs
-1 class

On Jun 28, 6:27 pm, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> -1 on request.response
>
> This looks simpler at first but it's actually just more typing always. If
> you don't care about the response object it's just :
>
> function (request) { ... }
>
> When you do care about response it's now 7 extra characters every time you
> reference it rather than 7 characters at the top of the function.
>
> -Mikeal
>
>
>
> On Mon, Jun 28, 2010 at 3:30 PM, Olly <oliver.mor...@kohark.com> wrote:
> > An example of using the http server:
> >https://gist.github.com/21c4d53ec77e7862232c
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

Olly

unread,
Jun 29, 2010, 6:21:56 AM6/29/10
to nodejs
The class idea isn't that important, i just had to have some way of
extending other classes, but that can quite easily be done using
prototypes, so not to worry.

Is there any feedback on the re-definition of streams, sockets and
servers. A socket binds to a port/address and listens to incoming
connections, a server manages clients requests / responses in an
application specific way, and a stream is whats produced by an
accepted connection from a socket.

Also the introduction of the flush() method, which would be useful in
HTTP where you'd want to manage output buffering on a lower level.

Camilo Aguilar

unread,
Jun 29, 2010, 9:07:41 AM6/29/10
to nod...@googlegroups.com
I'm agree with Bradley comments but this proposal looks much better than the current Node API. Good to know that there are still people who design. Good work Oliver.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

Marak Squires

unread,
Jun 29, 2010, 10:14:32 AM6/29/10
to nod...@googlegroups.com
-3 for class

CC

unread,
Jun 29, 2010, 10:39:52 AM6/29/10
to nod...@googlegroups.com
Hey!

Seems to be good for me. The syntax is clearly less confused. For
example I prefer "new http.server()" than "http.createServer(...)".
Isn't it simpler ?

New API or framework over the old one or patch, that's suits me !

2010/6/29 Marak Squires <marak....@gmail.com>:

Felix Geisendörfer

unread,
Jun 29, 2010, 10:54:55 AM6/29/10
to nodejs
What about casing? I like:

* UpperCamelCase for class names
* lowerCamelCase for variables and methods

It seems that is what most people (without a Ruby background) seem to
prefer in node/JS these days.

--fg

On Jun 29, 4:39 pm, CC <comandoc...@gmail.com> wrote:
> Hey!
>
> Seems to be good for me. The syntax is clearly less confused. For
> example I prefer "new http.server()" than "http.createServer(...)".
> Isn't it simpler ?
>
> New API or framework over the old one or patch, that's suits me !
>
> 2010/6/29 Marak Squires <marak.squi...@gmail.com>:
>
>
>
> > -3 for class
>
> > On Tue, Jun 29, 2010 at 9:07 AM, Camilo Aguilar <cam...@cloudescape.com>
> > wrote:
>
> >> I'm agree with Bradley comments but this proposal looks much better than
> >> the current Node API. Good to know that there are still people who design.
> >> Good work Oliver.

Scott González

unread,
Jun 29, 2010, 11:00:33 AM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 10:39 AM, CC <coman...@gmail.com> wrote:
Seems to be good for me. The syntax is clearly less confused. For
example I prefer "new http.server()" than "http.createServer(...)".
Isn't it simpler ?

Ryan has previously said that this is a change he would like to make. The reason we have http.createServer() is because there used to be a limitation with constructors between the JavaScript and C bindings, but that limitation no longer exists.

Peter Griess

unread,
Jun 29, 2010, 11:22:11 AM6/29/10
to nod...@googlegroups.com
Thanks for writing this up, Olly.

I've got a few comments, but in general I really like the direction that you're taking.
  • What does it mean for require() to be invoked without an argument?
  • I don't love the inheritance relationship between node and process. These seem like separate areas of functionality to me. Also, your docs have them both extending eachother ;)
  • Is process.id() a replacement for process.pid? Why the name change and switch from a primitive to a function?
  • What is process.cpu()? Is this intended to be a mechanism for tracking CPU usage? If so, it might be nice if it reported the system/user split. Also, there should be some expectation for how often this value is updated (is it a 1 minute average? 5? etc).
  • Where would an API for querying the state of the system-wide event loop live? As discussed before on the mailing list, it'd be useful to get a list of live event sources. Maybe in node.*?
  • I don't think I understand how the *.events namespace works on the different objects. Does this mean that to listen for the 'exit' event on the 'process' object, I'd have to do: process.exit.bind() or process.bind('exit', ...) or what? FWIW I really like the loose coupling that currently exists with addListener(<event-name>, ...) which is lost if we depend on the object having a member <event-name> at the time of binding.
  • What does events.emitter.reset() do?
  • I like the bind/unbind terminology for events. I don't think it's sufficient for unbind() to identify the callback to removed simply by function (event, object) tuple. What if I have registered the same callback multiple times and only wish to remove one. I think bind() needs to return an ID that can be passed to unbind(). Also, what does one need the 'context' parameter for?
  • Method which are dual-mode sync/async don't need both an async flag and a callback parameter. They just need a callback parameter -- if it's undefined, the invocation is synchronous.
  • What is net.stream.buffer?
  • I'd love an API into net.stream to determine how much data is buffered for write. Is this what the above is for?
  • I think it's worth considering moving net.stream into the IO module, since many of the methods are related to the stream-of-bytes interface, and unrelated to networking. net.stream should inherit from io.stream of course. Actually, I think tcp.stream should provide delay/timeout/end rather than net.stream.
  • net.stream.pause() and resume() should be moved into events.emitter.
  • I don't feel great about providing UDP support using the "stream" abstraction since it's unreliable, but there's enough machinery in there and the API is close enough that maybe it's not a huge deal.
  • For net.socket, are the 'port' and 'address' fields referring to local values or remote values? We should expose both and name them appropriately.
  • How do I use a created net.socket and connect to a remote host? I think we're missing the connect() API. The connect() API should be usable after a call to bind() to bind the socket to a specific local interface.
Peter

Jan Schütze

unread,
Jun 29, 2010, 11:42:02 AM6/29/10
to nod...@googlegroups.com
2010/6/29 Felix Geisendörfer <fe...@debuggable.com>:

> What about casing? I like:
>
> * UpperCamelCase for class names
> * lowerCamelCase for variables and methods
>
+1


--

http://dracoblue.net

samuel

unread,
Jun 29, 2010, 11:41:45 AM6/29/10
to nod...@googlegroups.com
Hello,
for the casing, and because I'm really to new in nodejs to speak about other thing,
A lot of convention exist for javascript like http://javascript.crockford.com/code.html why use ruby or other language convention.

2010/6/29 Peter Griess <p...@std.in>

Olly

unread,
Jun 29, 2010, 12:36:26 PM6/29/10
to nodejs
camelCasing is being avoided because its unnecessary. All properties,
classes and methods should only need 1 short word to describe their
purpose, if they need more then that then either your vocabulary is
limited, it needs namespacing, or its in the wrong place. Doing it
this way avoids upsetting either the camelCase or the underscore_crew.
And makes for a much more elegant API too.

I will answer some of the other questions in more detail when i get a
chance. Thanks to everyone for their input.

Mikeal Rogers

unread,
Jun 29, 2010, 12:46:48 PM6/29/10
to nod...@googlegroups.com
I'm actually partial to having:

new Server(port, host);

and the shorthand

createServer(port, host, listener);

Having the base object accessible is nice and the createServer call is simply shorthand. A single all lowercase "server" function is somehow confusing if it's returning a big ass object.

-Mikeal

Mikeal Rogers

unread,
Jun 29, 2010, 12:48:18 PM6/29/10
to nod...@googlegroups.com
This looks cleaner if you already know the API but is confusing for new users.

A lot this API seems like it's be reduced for the sake of people who have been using it for a while and want a little less typing and shift-key work but it's all a little too terse for new users IMO.

-Mikeal


--

Isaac Schlueter

unread,
Jun 29, 2010, 1:26:14 PM6/29/10
to nod...@googlegroups.com
In JavaScript, constructors usually start with a capital letter.
Error, Array, Object, Function, etc. If you use "new", it should be
capitalized.

new http.server() is thus not as good as new http.Server().

It's not about what's better, it's about what's already the standard.
No one ever said JavaScript was the prettiest language ever :)


How do you guys feel about multi-purposing the constructors to return
a new object even if called directly? It's pretty simple in the code.

function Server () {
if (!(this instanceof Server)) return new Server();
...
}

Then you can do stuff like:
require("http").Server().addListener("connect", cb).listen(8888)

--i

Isaac Schlueter

unread,
Jun 29, 2010, 1:26:39 PM6/29/10
to nod...@googlegroups.com
Oh, also, we should probably do this on a wiki or something. Email is
ill suited to this task, I think. Even a gist with comments would be
much better.

--i

Ryan Gahl

unread,
Jun 29, 2010, 1:37:36 PM6/29/10
to nod...@googlegroups.com
-1 for UpperCamelCase

much prefer all lowerCamelCase

var foo = new http.server(); // yay, no superfluous big letters to worry about having to remember

var foo = new Http.Server(); // blech (oh wait, or is it http.Server()... or... blech)




2010/6/29 Felix Geisendörfer <fe...@debuggable.com>

Stephen Belanger

unread,
Jun 29, 2010, 1:40:26 PM6/29/10
to nod...@googlegroups.com
I agree on that; all lowercase with deep namespacing would be nice. 

Isaac Schlueter

unread,
Jun 29, 2010, 1:50:18 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 10:40, Stephen Belanger <cyruz...@gmail.com> wrote:
> On Tue, Jun 29, 2010 at 10:37 AM, Ryan Gahl <ryan...@gmail.com> wrote:
>>
>> -1 for UpperCamelCase
>> much prefer all lowerCamelCase
>> var foo = new http.server(); // yay, no superfluous big letters to worry
>> about having to remember
>> var foo = new Http.Server(); // blech (oh wait, or is it http.Server()...
>> or... blech)

You only uppercase the class, not the module. It's actually very
consistent, working today, and gels with the rest of the JavaScript
language.

Is it problematic to remember Array or Buffer or TypeError?

--i

Ryan Gahl

unread,
Jun 29, 2010, 2:06:10 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 12:50 PM, Isaac Schlueter <i...@izs.me> wrote:
You only uppercase the class, not the module.  It's actually very
consistent, working today, and gels with the rest of the JavaScript
language.

Is it problematic to remember Array or Buffer or TypeError?


It's not so much problematic to remember stuff like this (it's an API, if you use it you know the casing and other idiosyncrasies out of necessity), but IMHO all lowercase is more elegant. If I had my way, only the ECMA standard system types would be uppercased.






Mikeal Rogers

unread,
Jun 29, 2010, 2:15:38 PM6/29/10
to nod...@googlegroups.com
I can't believe this is even a discussion.

JavaScript does unpredictable things when you call objects that should be instantiated with a new operator without them. I'm certainly not a style nazi but beginning with UpperCase for all objects that need to be instantiated with a new operator is probably the most important convention you can use.

Can we just stick with Crockford or Mozilla's style guide so that we can avoid these discussions in the future? Maybe we need to create a node style guide that a hybrid of Mozilla/Crockford with comma-first :)

-Mikeal

Marak Squires

unread,
Jun 29, 2010, 2:18:48 PM6/29/10
to nod...@googlegroups.com
javascript has a new operator?

Ryan Gahl

unread,
Jun 29, 2010, 2:25:20 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 1:15 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
I can't believe this is even a discussion.


Apparently it's not a discussion.

but, FWIW: fuck comma-first

Stephen Belanger

unread,
Jun 29, 2010, 2:38:05 PM6/29/10
to nod...@googlegroups.com
What's wrong with comma-first? It's much easier to spot errors, and I find it's just as readable.

Also, I agree that base objects should be capitalized. Everything else should be lower case though; I've had far too many bugs pop up with camel-casing when I forget a parenthesis. For example;

Class.methodOtherClass.property);

It's not immediately obvious that the opening parenthesis needs to be right after "method" if you are using camel casing. But with base-class capitalization and methods/properties of the class being all lowercased it's much easier to spot.

--

Mikeal Rogers

unread,
Jun 29, 2010, 2:53:41 PM6/29/10
to nod...@googlegroups.com
let's not have the comma first argument on this thread, there is plenty to argue about that is actually in the proposal.

Ryan Gahl

unread,
Jun 29, 2010, 3:23:52 PM6/29/10
to nod...@googlegroups.com

On Tue, Jun 29, 2010 at 1:53 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
let's not have the comma first argument on this thread, there is plenty to argue about that is actually in the proposal.


:)

+1 (I was initially just commenting on something that had already been brought up with the casing and then had to barf on comma-first when I saw it mentioned, back on topic now...)


So, here's some API related content: I actually like the inheritance model from Prototype quite a bit. I don't think we need Class.create() at all or anything like that (i.e. it's a bit convoluted to re-wire the constructor to match an "intitalize" function on the prototype, but I do think we can borrow from them for an Object.inherit() method (not messing with Object's prototype but as a mixin)...

So:

namespace.Something = function() {...} //constructor 

namespace.Something2 = function() {...} //subclass
Object.inherit(namespace.Something, namespace.Something2); //Something2 now inherits from Something

//or...
namespace.Something2 = Object.inherit(namespace.Something, {
//override doSomething
doSomething: function($super, arg1, arg2) {
//call base class method
$super(arg1, arg2);
}
});


There's a tiny amount of well-tested and working static analysis at inherit-time to wire the magic $super keyword. I have such an implementation working in my own stuff (just adapted that model without bringing in any other Prototype stuff). Quite useful, IMHO.

Felix Geisendörfer

unread,
Jun 29, 2010, 3:37:31 PM6/29/10
to nodejs
I think node should only provide the *minium* of what can be described
as 'inheritance'. I'm very happy with sys.inherits doing the job at
this point.

For everything else, there is http://code.google.com/p/joose-js/
(strange loops ahead, you've been warned).

--fg

On Jun 29, 9:23 pm, Ryan Gahl <ryan.g...@gmail.com> wrote:

Marco Rogers

unread,
Jun 29, 2010, 3:46:40 PM6/29/10
to nodejs
-1 to class. It looks like you're proposing to add the "extends"
method to the Object prototype. Definitely -1 to that.

Sys.inherits doesn't do anything fancy. It's one function and easy
for newbs to deconstruct. Providing what looks like a real API around
inheritance will just result in people being confused about why it
doesn't work elsewhere (see process.mixin debacle). And if people do
start using this convention in node, they'll have to drag around a
shim so the same code will work elsewhere. There's going to be a lot
of that going on anyway, but let's not add to the problem.

Also, what is class.prototype.events for?

My only opinion on the rest is that I agree with Mikeal. Shortening
things for the sake of brevity is not worth raising the barrier to
newcomers. I have opinions about case as well, but I also realize
they don't matter. Let ry make the call and I'll live with it.

:Marco

PS - Has ry actually been declared BDFL? I have certainly been
thinking that subconciously for a while now. Any time I'm thinking of
a change I think "I gotta convince ry that..." FYI, it has yet to
happen ;)

On Jun 29, 3:23 pm, Ryan Gahl <ryan.g...@gmail.com> wrote:

Mikeal Rogers

unread,
Jun 29, 2010, 3:50:52 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 12:46 PM, Marco Rogers <marco....@gmail.com> wrote:
-1 to class.  It looks like you're proposing to add the "extends"
method to the Object prototype.  Definitely -1 to that.

I'll go further and say -1 to anything that adds methods to the base object prototypes.

-Mikeal

Isaac Schlueter

unread,
Jun 29, 2010, 4:02:05 PM6/29/10
to nod...@googlegroups.com
I DO HEREBY DECLARE RY BDFL OF NODEJS.

On Tue, Jun 29, 2010 at 12:46, Marco Rogers <marco....@gmail.com> wrote:
> PS - Has ry actually been declared BDFL?

Yes.

--i

Ryan Gahl

unread,
Jun 29, 2010, 4:02:25 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 2:50 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
I'll go further and say -1 to anything that adds methods to the base object prototypes.


As for my comments about inheritance, I very specifically said "does not mess with Object's prototype but added as a mixin..."

I can agree with the argument about keeping things light, but thought we were starting to round out the API a bit with this blue-sky discussion. An Object.inherit mixin would be a convenience thing for cases where rich OO modelling is desired. Putting the method in the "Object" namespace seems intuitive to me, since we're dealing with an OO concept here, but it doesn't necessarily have to move there.

Providing an "inheritance" method at all, but not taking it a bit further and enabling common tasks associated with inheritance (method overriding, for example) seems like we're not trying to really think about a complete API (at least IRT this particular method).

I don't think that "developers will have to carry a shim around when they go to another platform" argument makes a whole lot of sense when talking about "the node API" either.

Marak Squires

unread,
Jun 29, 2010, 4:03:18 PM6/29/10
to nod...@googlegroups.com
YIP YIP HUZAAH

Marco Rogers

unread,
Jun 29, 2010, 4:04:45 PM6/29/10
to nod...@googlegroups.com
I'm opposed to extending the other basic data types like String or Array.  Usually you're adding helpful manipulation methods.  And if you're adding anything else you do so at your own peril.  As long as you don't break the constructors you're unlikely to run into issues.  Most people use these datatypes in a consistent manner and don't extend them directly.  But if you change Object, that has ripples throughout the system and it severely hampers your ability to reason about inherited/polymorphic behaviors.

A contrived example.  I'm writing some game library with a class DrawBridge.  I add the method DrawBridge.prototype.extend in order to let me Troops in.  In the course of my app running, I get an object which I expect to be a DrawBridge.  Instead it's some other type.  But it still responds to extend, so it must be a duck right?  Now I have to debug some weird behavior.

Essentially duck typing only works if library writers work in their own silos with their own objects.  As soon as you start littering the object prototype, you infest everyone else's code.  It's just as bad as globals.  Yes I realize node module sandboxes sidestep this issue, but the browser doesn't and probably won't for a good while.

:Marco

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.



--
Marco Rogers
marco....@gmail.com

Life is ten percent what happens to you and ninety percent how you respond to it.
- Lou Holtz

Ryan Gahl

unread,
Jun 29, 2010, 4:07:57 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 3:04 PM, Marco Rogers <marco....@gmail.com> wrote:
But if you change Object, that has ripples throughout the system and it severely hampers your ability to reason about inherited/polymorphic behaviors.

-1 to modifying Object.prototype 

-10 to people not reading things completely and beginning side discussions that are moot because the original person specifically said "doesn't mess with Object's protoype..."

:)

Saikat Chakrabarti

unread,
Jun 29, 2010, 4:10:45 PM6/29/10
to nod...@googlegroups.com

Marco Rogers

unread,
Jun 29, 2010, 4:37:58 PM6/29/10
to nod...@googlegroups.com
Yeah I'm guilty of replying to follow-ups rather than fully reading the OP.  My bad.  The Object.prototype discussion ended up sidetracking me but I'm still opposed to class anyway.  Object inheritance is important enough for you to make a conscious decision how you want to handle it.  There are already a billion libs available.  I don't think we should be adding a "blessed" implementation of any kind.  It's just not necessary IMO.  

If you look at the api right now it's pretty lean.  Most of the modules are "necessary" because they require constructs that don't exist in plain js (fs, net, etc).  The few that are plain js, (url, querystring), are "necessary" to fs or http.  They're just broken out to increase modularity.

:Marco

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Ryan Gahl

unread,
Jun 29, 2010, 4:47:22 PM6/29/10
to nod...@googlegroups.com
That's all good in the hood.

Was just throwing out some food for thought. 

Is everything that's deemed "unnecessary" going to be shot down, though? I don't think it's a great long term philosophy, just for the sake of "keeping things light". Light is good, but an API should also be robust and cut down on work for common tasks. In other words, at some point I hope we can add some convenience stuff to the API because of it's broad utility and just say "this adds value to the API and the implementation is fast and sound so in it goes" rather than "wellll... that COULD be pulled in as a library, so therefore it's out". The inheritance discussion isn't necessarily something I'd complain too loudly about not including, but in general, if we're starting to seriously discuss a new API I'd think we can err on the side liberally allowing things into the proposal and then scrutinize each item's overall value in the API before finalizing the spec.

Marco Rogers

unread,
Jun 29, 2010, 5:09:05 PM6/29/10
to nod...@googlegroups.com
Yeah I hear you.  I'm certainly not opposed to making node more user-friendly.  But in most cases it doesn't need to go into the core api.  I liked the idea that was proposed a while back of having a node "distro".  It would include node core and a bunch of other useful packages pre-installed.  My opinion on the node api is that it should stay lean and anything else should be in userland.  But if you wanted a really small environment, you can still get that easily.

/begin rant

The problem I have with a lot of platforms/frameworks these days is that it's impossible to get a complete picture of what it does or doesn't do.  There's so much stuff crammed into it that you can't touch anything without "hacking core".  Not to mention the fact that the bigger an api gets, the harder it is to maintain good documentation and the faster tutorials become outdated.

I really like the fact that you can absorb the whole of node's api easily in one sitting and be pretty comfortable with it's capabilities.  Anything else you see goes into a different mental bucket.  You can assume it's not critical for node to operate and if you modify it, you won't be breaking any core functionality. Also it has it's own docs separate form core, which should be smaller and also easier to absorb.  And if it doesn't have docs, our newly christened BDFL doesn't have to put up with support requests for core.  We also avoid people griping about "holes in the docs."

When these things are done badly, it makes a particular platform much less attractive to me.  I would like node to avoid these if possible while still achieving it's goals.

/end rant

With that being said.  I would be interested in a separate thread about additional stuff that node doesn't have.

:Marco

Stephen Belanger

unread,
Jun 29, 2010, 5:38:19 PM6/29/10
to nod...@googlegroups.com
I agree. I'd much rather have a lean core with a bunch of "official" libraries/modules available if needed. The more generic the core is the better--then we can more easily just plug in what we need and ignore what we don't.

Mikeal Rogers

unread,
Jun 29, 2010, 5:47:42 PM6/29/10
to nod...@googlegroups.com
The more Ryan's node as linux kernel model sinks in to my head the more anal I get about node-core growing in size.

There are a lot of opinions about the higher level API (see Promises) that have such a large impact that integrating any proposal makes the platform different enough that it's basically own distribution. 

The list of "official" libraries/modules that would encompass a stdlib will be built on top of those API decisions and make up the distribution.

This also means that node core will be slim and targeted enough that it's easy to grok on it's own.

-Mikeal

Jan Schütze

unread,
Jun 29, 2010, 5:51:02 PM6/29/10
to nod...@googlegroups.com
> console.log()
> console.write()
> console.debug()

It would be cool to follow any of the conventions set by firebug or
log4j. console.log, console.warn, console.info etc.

About naming and namespacing. The modules and their usage in node.js
look usually like this at the moment.

var events = require('events');
// we can do
new events.Emmitter();
// or
var Emmitter = events.Emmitter;
new Emmitter();
// or whatever!

This means, we currently have (and I like that) put our required
module in any variable we want to --- anyways.

This is awesome if you have a sub sub module like this:

var submodule = require("module/submodule");

This is what we have now and how we use modules. It works pretty much
like import at java:

import events.Emmiter;
// now Emmiter is available

This is convinient and helpful ;). Please keep it that way.

About capital letters for Constructor Functions. It helps reading, got
suggested by many and is de facto standard in _many_ libraries. Using
a lowercase letter brings in my opinion no real benifit. When you
actually have to read code, and see a "new whatever" statement, you
can be pretty sure, that it's wrong. a call like:
myobject.DestroyUniverse is pretty much wrong, too. On first sight. So
why remove this convention just in node?


node.object: what is this? I see many objects extending the node.object.

About the small node core. For me node is a framework to build
frameworks. It works great, evented and has a javascript interface. It
ships all the methods used to create a console or web app. And in my
opinion, it shouldn't deliver more. No bindings to databases or stuff,
this is a task for a plugins and may be put into a distro.
But I guess I wouldn't have started so easly with nodejs, when I had
to "git clone" a http plugin and stuff, before I could begin ;).

Regards,
Jan

Mikeal Rogers

unread,
Jun 29, 2010, 5:53:05 PM6/29/10
to nod...@googlegroups.com
Are these also followed by Chrome and Firefox's builtin consoles?

-Mikeal

2010/6/29 Jan Schütze <Ja...@dracoblue.de>

Olly

unread,
Jun 29, 2010, 7:16:54 PM6/29/10
to nodejs
I have begun writing the new API in javascript using empty methods
which can easily be replace by code.Watch this repository:

http://github.com/ollym/node-api

i'll be uploading it soon. Also feel free to fork it and provide your
own ideas.

Im in favour of keeping everything lowercase and using native js
prototypes instead of fancy class classes. Im not a fan of
sys.inherits either. If speed is node's primary goal (which it kinda
is) its important to A) Use as little objects as possible, and B) use
JS the way its designed to be.

I also appologise for all those who actually took the time to read my
API and found all the errors!! I appreciate you taking the time to
actually read through it, and im sorry for not being more thorough, i
had no idea this would attract so much attention!

Mikeal Rogers

unread,
Jun 29, 2010, 7:19:22 PM6/29/10
to nod...@googlegroups.com
Im in favour of keeping everything lowercase and using native js
prototypes instead of fancy class classes. Im not a fan of
sys.inherits either. If speed is node's primary goal (which it kinda
is) its important to A) Use as little objects as possible, and B) use
JS the way its designed to be.

Are you high?

-Mikeal

Mikeal Rogers

unread,
Jun 29, 2010, 7:24:54 PM6/29/10
to nod...@googlegroups.com
Sorry, that was terse.

Really though, object overhead?

Not that object overhead is anywhere close to mattering in terms of performance optimizations but just for your information creating an object use new is actually faster in v8 than even using an object literal. isaacs benchmarked it. But it doesn't matter in, the difference here is so small that it is actually inconsequential.

"use js the way it's designed to be". Ok, so like *every* organization and person that has been around for a while in javascript uses camelCase and capitalizes the first letter of objects that are instantiated with a new operator.

Is the purpose of this exercise to get people to have a good discussion about your API so that you can just write what you want anyway or do you actually want to get this in to node?

-Mikeal

Preston Guillory

unread,
Jun 29, 2010, 7:37:41 PM6/29/10
to nod...@googlegroups.com
Firstly, +1 to a brutally minimal core

Secondly, the idea of wholesale, blue-sky API redesign at this stage of Node's lifecycle makes me nervous.  True, the version number starts with 0.1, but in my opinion Node is already quite robust and functional.  I would rather see API changes discussed one at a time: let's change feature X for reason Y.  I don't really know how to have a proper discussion about a big batch like this.

I guess my two favorite words are minimal and incremental.

Isaac Schlueter

unread,
Jun 29, 2010, 7:43:40 PM6/29/10
to nod...@googlegroups.com
+1 to Preston and Mikeal's comments.

It'd be better, in cases like this, to do an inventory of what's there
*already*, and then make the minimal changes necessary to increase
consistency and functionality.

Note that "minimum necessary" might be quite large. (Qv. the whole
"stream API" revolution that's been going on for the last few months.)
But changing a name just cuz it looks nice, that's not ideal.


(Also, Olly, you'll probably find that most people on this list pay a
lot of attention to everything that happens on it. NodeJS has a very
attentive and outspoken community ;)

--i

Olly

unread,
Jun 29, 2010, 7:46:48 PM6/29/10
to nodejs
Sorry, that was not explained very well.

I quote RY(Ryan) "Node.JS is fast until it hits the GC". The GC is
with use of objects. Use in moderation i think.

On Jun 30, 12:24 am, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> Sorry, that was terse.
>
> Really though, object overhead?
>
> Not that object overhead is anywhere close to mattering in terms of
> performance optimizations but just for your information creating an object
> use new is actually faster in v8 than even using an object literal. isaacs
> benchmarked it. But it doesn't matter in, the difference here is so small
> that it is actually inconsequential.
>
> "use js the way it's designed to be". Ok, so like *every* organization and
> person that has been around for a while in javascript uses camelCase and
> capitalizes the first letter of objects that are instantiated with a new
> operator.
>
> Is the purpose of this exercise to get people to have a good discussion
> about your API so that you can just write what you want anyway or do you
> actually want to get this in to node?
>
> -Mikeal
>

Marco Rogers

unread,
Jun 29, 2010, 7:48:22 PM6/29/10
to nod...@googlegroups.com, nod...@googlegroups.com
It should be noted that sys.inherits isn't part of the public node API. It's not on the docs page (intentional?). It's just a convenience method used by core, but other lib developers also picked it up.  I would be okay if it went away and people either used basic js inheritance or just grabbed one of the other readily available modules from userland.

Lord knows it couldn't cause more of a stink than removing process.mixin did.

Sent from my iPhone

r...@tinyclouds.org

unread,
Jun 29, 2010, 8:10:04 PM6/29/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 4:48 PM, Marco Rogers <marco....@gmail.com> wrote:
> It should be noted that sys.inherits isn't part of the public node API. It's
> not on the docs page (intentional?).

Yes, intentional. Private APIs are hard in JS - there is no way to
enforce it. My way has been this: not in api.markdown then not public
and maybe removed without notice.

Mark S. Miller

unread,
Jun 29, 2010, 9:26:14 PM6/29/10
to nod...@googlegroups.com, Tom Van Cutsem
[+tvcutsem]

On Tue, Jun 29, 2010 at 12:23 PM, Ryan Gahl <ryan...@gmail.com> wrote:

On Tue, Jun 29, 2010 at 1:53 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
let's not have the comma first argument on this thread, there is plenty to argue about that is actually in the proposal.


:)

+1 (I was initially just commenting on something that had already been brought up with the casing and then had to barf on comma-first when I saw it mentioned, back on topic now...)


So, here's some API related content: I actually like the inheritance model from Prototype quite a bit. I don't think we need Class.create() at all or anything like that (i.e. it's a bit convoluted to re-wire the constructor to match an "intitalize" function on the prototype, but I do think we can borrow from them for an Object.inherit() method (not messing with Object's prototype but as a mixin)...

I prefer Trait.create(). See <http://traitsjs.org/>

 

So:

namespace.Something = function() {...} //constructor 

namespace.Something2 = function() {...} //subclass
Object.inherit(namespace.Something, namespace.Something2); //Something2 now inherits from Something

//or...
namespace.Something2 = Object.inherit(namespace.Something, {
//override doSomething
doSomething: function($super, arg1, arg2) {
//call base class method
$super(arg1, arg2);
}
});


There's a tiny amount of well-tested and working static analysis at inherit-time to wire the magic $super keyword. I have such an implementation working in my own stuff (just adapted that model without bringing in any other Prototype stuff). Quite useful, IMHO.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.



--
    Cheers,
    --MarkM

Aaron Heckmann

unread,
Jun 30, 2010, 12:38:51 AM6/30/10
to nod...@googlegroups.com
+1 console
-1 class
+1 UpperCamelCase for class names
+1 lowerCamelCase for variables and methods
+1 minimal changes necessary to increase consistency and functionality
+1 for:
  function Server () {
    if (!(this instanceof Server)) return new Server();
    ...
Aaron
http://clickdummy.net

Ryan Gahl

unread,
Jun 30, 2010, 10:17:59 AM6/30/10
to nod...@googlegroups.com
On Tue, Jun 29, 2010 at 11:38 PM, Aaron Heckmann <aaron.h...@gmail.com> wrote:
+1 console
-1 class
+1 UpperCamelCase for class names
+1 lowerCamelCase for variables and methods
+1 minimal changes necessary to increase consistency and functionality
+1 for:

  function Server () {
    if (!(this instanceof Server)) return new Server();
    ...
  }



Soooo.... +4 ?

Dean Landolt

unread,
Jun 30, 2010, 10:55:54 AM6/30/10
to nod...@googlegroups.com
On Wed, Jun 30, 2010 at 12:38 AM, Aaron Heckmann <aaron.h...@gmail.com> wrote:
+1 console
-1 class
+1 UpperCamelCase for class names
+1 lowerCamelCase for variables and methods
+1 minimal changes necessary to increase consistency and functionality
+1 for:

  function Server () {
    if (!(this instanceof Server)) return new Server();
    ...
  }


+1 to all this ^^ 

Marco Rogers

unread,
Jun 30, 2010, 11:24:46 AM6/30/10
to nod...@googlegroups.com
I'm not crazy about mucking with the constructor to avoid new.  I totally get the chaining thing, but that can be accomplished in other ways.  Not a huge deal if people like it though.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.



--

Tom

unread,
Jun 30, 2010, 11:31:45 AM6/30/10
to nod...@googlegroups.com
I didn't read all this but I can say that the whole require with a literal string thing seems very ugly to me.

Eg.:

var net:Net = require("net");

While in my opinion this should be 

var net:Net = new Net();

or, simply Net if it's a static class and require an import at the top:

import Net;

Regards,
Tom

2010/6/30 Marco Rogers <marco....@gmail.com>

Scott González

unread,
Jun 30, 2010, 12:08:49 PM6/30/10
to nod...@googlegroups.com
On Wed, Jun 30, 2010 at 11:31 AM, Tom <tomm...@gmail.com> wrote:
I didn't read all this but I can say that the whole require with a literal string thing seems very ugly to me.

This thread sure is having some trouble staying on topic. We're not debating the constructs of the JavaScript language.

Stephen Belanger

unread,
Jun 30, 2010, 12:20:00 PM6/30/10
to nod...@googlegroups.com
On the note of constructors--I like the way Kohana manages this; It leaves the constructor alone and creates a seperate function called factory. Thus; Class::factory() returns a chainable instance.

2010/6/30 Scott González <scott.g...@gmail.com>
On Wed, Jun 30, 2010 at 11:31 AM, Tom <tomm...@gmail.com> wrote:
I didn't read all this but I can say that the whole require with a literal string thing seems very ugly to me.

This thread sure is having some trouble staying on topic. We're not debating the constructs of the JavaScript language.

--

Isaac Schlueter

unread,
Jun 30, 2010, 2:09:47 PM6/30/10
to nod...@googlegroups.com
> 2010/6/30 Scott González <scott.g...@gmail.com>
>> On Wed, Jun 30, 2010 at 11:31 AM, Tom <tomm...@gmail.com> wrote:
>>> I didn't read all this but I can say that the whole require with a
>>> literal string thing seems very ugly to me.
>>
>> This thread sure is having some trouble staying on topic. We're not
>> debating the constructs of the JavaScript language.

That's not a construct of the JavaScript language, but it is a
construct of the CommonJS module spec.

We're not going to move away from that, I hope.

--i

Tom

unread,
Jun 30, 2010, 2:42:56 PM6/30/10
to nod...@googlegroups.com
I don't understand why CommonJS started this way of constructing and I personally do hope node is moving away from it. :)

Javascript has normal object construction, eg. new someClass() - why not use it? Seems much cleaner than require("someClass")

- Tom

2010/6/30 Isaac Schlueter <i...@izs.me>

Dean Landolt

unread,
Jun 30, 2010, 2:47:20 PM6/30/10
to nod...@googlegroups.com
On Wed, Jun 30, 2010 at 2:42 PM, Tom <tomm...@gmail.com> wrote:
I don't understand why CommonJS started this way of constructing and I personally do hope node is moving away from it. :)

Javascript has normal object construction, eg. new someClass() - why not use it? Seems much cleaner than require("someClass")

How do you plan on getting someClass into scope? From your prior email it looks like you may be confusing ActionScript and ECMAScript. We can't just import Net here in javascriptland.

Ryan Gahl

unread,
Jun 30, 2010, 2:47:31 PM6/30/10
to nod...@googlegroups.com
I think you're confused about what require() does. It's not a way to create instances, it imports code from another file.

var someLib = require("someLib");

means that the someLib variable will contain whatever the "someLib.js" file puts onto its exports object, which I guess COULD be instances of things, but usually should be various helper functions and/or constructors.

Tom

unread,
Jun 30, 2010, 2:49:01 PM6/30/10
to nod...@googlegroups.com
You're right. Then I guess I wish there would be such constructors, but that may not be possible with Javascript.

- Tom

2010/6/30 Ryan Gahl <ryan...@gmail.com>

Mikeal Rogers

unread,
Jun 30, 2010, 2:50:15 PM6/30/10
to nod...@googlegroups.com
The require system wasn't pulled out of thin air, it has a list of goals and requirements and this was the result.

There are a lot of security and sandboxing considerations that went in to Modules as well which is some of the reason why it's a little more work to write a commonjs module than a traditional script because you don't just want to let that module jam itself all over the global namespace.

-Mikeal

Scott González

unread,
Jun 30, 2010, 3:14:25 PM6/30/10
to nod...@googlegroups.com
On Wed, Jun 30, 2010 at 2:09 PM, Isaac Schlueter <i...@izs.me> wrote:
> 2010/6/30 Scott González <scott.g...@gmail.com>

>> This thread sure is having some trouble staying on topic. We're not
>> debating the constructs of the JavaScript language.

That's not a construct of the JavaScript language, but it is a
construct of the CommonJS module spec.

We're not going to move away from that, I hope.

I was referring to the comment about using the non-existent import statement.
Reply all
Reply to author
Forward
0 new messages