--
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.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
If a new solution is made, it should probably target the simple need
for things like creating sub-"classes" of EventEmitter and other core
classes rather than just be a utility. Right now I only use
sys.inherits because it pretty much guarantees that my code works the
same way as a large part of the core library when extending things.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
Right now I only use
sys.inherits because it pretty much guarantees that my code works the
same way as a large part of the core library when extending things.
This could easily be handled by a Node compatibility layer but I just
haven't bothered to get there.
~ Anders
It wouldn't be hard to approximate sys.inherits, though it does use
some ES5 properties like enumerable flags on Object.create. Of course,
the code itself will work find in many new browsers so one could
implement it via cut and paste with a feature detection call. Not
perfect but if the behavior and caveats are well documented, I don't
see a problem.
For those that want a different class system, it would be easy to
expose an informat protocol based on the existence of a method on the
super's prototype that is run instead. Just a thought.
Brian.
Aaron, can
you elaborate on the problems you've seen with Class implementations
in node? I'm curious.
I think this is a good argument for removing sys.inherits, or at least
not exposing it to user code. There is a core JavaScript language, and
it does not have any concept of classes, or of the kind of class-based
inheritance that people sometimes want to bolt on.
Developers who want that kind of experience are free to use any number
of existing libraries that provide it, but Node itself should use the
core language as it exists, just as browsers do, and not try to turn
it into something it is not.
Node is not a good place for extensions to the core language.
NodeJS is not a JavaScript class library, or a language extension, or
anything else. Let's not bikeshed this. It's working, and simple.
You can use it. If you don't like it, it's super easy to write your
own, or just use __proto__ or Object.create() or whatever other method
you like.
--i
Right. Also consistent so specialization of node facilities can be done.
> NodeJS is not a JavaScript class library, or a language extension, or
> anything else. Let's not bikeshed this. It's working, and simple.
> You can use it. If you don't like it, it's super easy to write your
> own, or just use __proto__ or Object.create() or whatever other method
> you like.
I'm not sure we are bikeshedding this (calling something a bikeshed is
a bikeshed itself anyway). We could easily allow people to use any
method they want. If they develop an inferiority complex in their code
because of node not using their flavor of things by default then they
probably shouldn't be coding in JavaScript [0]. I'm interested in
simple tools we can use to improve how people use node. sys.inherits
isn't perfect but it is practical and small. Also, for a good portion
of what it does, it's easy to emulate if not literally use (assuming a
form of Object.create is there) in browsers. The only case that comes
up is a problem either way in the browsers that don't implement an
ES-5 Object.create [1]. Also the specific pattern it implements is
actually pretty common in many libraries.
If someone wants to improve sys.inherits w/o adding significant
complexity, be my guest, but I plan on using whatever core uses for
now. Removing access to it would just be an inconvenience, pretending
that node doesn't already extend the language in small and important
ways (like commonjs module support ... I'm sure we could argue for
ages if we decided modules were a bikeshed).
Brian.
[0] Seriously, JS is flexible! So, why not worry about composition of
solutions rather than single solutions?
[1] i.e. {enumerable: false} on prototype properties passed to Object.create.
> It could literally display
> the full source of sys.inherits so people understand that there is no
> magic happening.
Don't people just do Function#toString in the repl for everything they use?
node> console.log(require("sys").inherits.toString())
function (ctor, superCtor) {
ctor.super_ = superCtor;
ctor.prototype = Object.create(superCtor.prototype, {
constructor: {
value: ctor,
enumerable: false
}
});
}
It's magical. But it's the standard JS magic we all know and love :)
--i
We should probably add a .show like the other dot-phrases or something
like it in the REPL. I know I use it but I hate typing it out. I'd
probably use it more often... I guess that's like volunteering a
patch. Maybe I'll take a crack at it later tonight. Feel free to beat
me to it in the mean time.
Brian.