sys.inherits

158 views
Skip to first unread message

Aaron Heckmann

unread,
Jul 28, 2010, 3:01:03 PM7/28/10
to nod...@googlegroups.com
I'm seeing a lot of developers using sys.inherits in their projects. It's quite useful. Is it time to expose this and add it to the docs?

--
Aaron
http://clickdummy.net

Elijah Insua

unread,
Jul 28, 2010, 3:15:29 PM7/28/10
to nod...@googlegroups.com
sys.inherits has actually been deprecated/removed.  The current best practice is to roll your own, or use an existing userland library.

-- Elijah

--
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.

Aaron Heckmann

unread,
Jul 28, 2010, 3:26:25 PM7/28/10
to nod...@googlegroups.com
Very good to know.
--
Aaron
http://clickdummy.net

Renato Elias

unread,
Jul 28, 2010, 3:29:57 PM7/28/10
to nod...@googlegroups.com
Javascript have the prototype chain, is native and simple:

var SuperClass = function() {
   this.name = "zz";
}

SuperClass.prototype.anyMethod = function() {
  return "bla";
}

var Extender = function() {
    SuperClass.call(this);
    console.log(this.name);  
}

Extender.prototype = new SuperClass;

var z = new Extender();
z.anyMethod();

Marco Rogers

unread,
Jul 28, 2010, 3:31:56 PM7/28/10
to nodejs
It has not been officially deprecated as far as I know. It is still
available in 0.1.102. The usual method is to have the function throw
a deprecation error.

This can definitely go in userland so I say let's pull the trigger on
removing it.

:Marco

On Jul 28, 3:26 pm, Aaron Heckmann <aaron.heckm...@gmail.com> wrote:
> Very good to know.
>
>
>
>
>
> On Wed, Jul 28, 2010 at 3:15 PM, Elijah Insua <tmp...@gmail.com> wrote:
> > sys.inherits has actually been deprecated/removed.  The current best
> > practice is to roll your own, or use an existing userland library.
>
> > -- Elijah
>
> > On Wed, Jul 28, 2010 at 3:01 PM, Aaron Heckmann <aaron.heckm...@gmail.com>wrote:
>
> >> I'm seeing a lot of developers using sys.inherits in their projects. It's
> >> quite useful. Is it time to expose this and add it to the docs?
>
> >> --
> >> Aaron
> >>http://clickdummy.net
>
> >> --
> >> 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>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/nodejs?hl=en.
>
> >  --
> > 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>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> --
> Aaronhttp://clickdummy.net

Aaron Heckmann

unread,
Aug 2, 2010, 4:08:40 PM8/2/10
to nod...@googlegroups.com
The only thing about deprecating/removing sys.inherits is that Node uses it quite a bit, so it's not likely to go away. Why not just expose it since many find it useful?

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.




--
Aaron
http://clickdummy.net

Marco Rogers

unread,
Aug 2, 2010, 5:38:20 PM8/2/10
to nodejs
It seems like we don't really have a consensus on what to do with
little utilities like this. In a previous conversation, most people
agreed that it should be in userland, except for the fact that it's
used extensively by core. I am in the camp that doesn't care if it
goes away or gets promoted to the official API. I would just like to
pick one. The fact is it's not really doing any harm in this nebulous
state, besides setting off my OCD. But eventually it will be
pervasive enough in userland code that the decision will be made for
us and we won't be able to get rid of it easily. I think this is one
of those decisions that should be made before 0.2.0 because many
people will have to update their code.

:Marco


On Aug 2, 4:08 pm, Aaron Heckmann <aaron.heckm...@gmail.com> wrote:
> The only thing about deprecating/removing sys.inherits is that Node uses it
> quite a bit, so it's not likely to go away. Why not just expose it since
> many find it useful?
>
> > <nodejs%2Bunsu...@googlegroups.com<nodejs%252Bunsubscribe@googlegroups. com>
>
> > > >> .
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/nodejs?hl=en.
>
> > > >  --
> > > > 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>
> > <nodejs%2Bunsu...@googlegroups.com<nodejs%252Bunsubscribe@googlegroups. com>

tjholowaychuk

unread,
Aug 3, 2010, 10:19:03 AM8/3/10
to nodejs
I dont get why we have sys.inherits() at all, all I ever need is:

function Animal(name) {
this.name = name;
}

function Dog(name) {
Animal.call(this, name);
}

Dog.prototype.__proto__ = Animal.prototype;

var simon = new Dog('simon');

console.assert(simon.name === 'simon');
console.assert(simon instanceof Dog);
console.assert(simon instanceof Animal);
console.assert(simon.constructor === Dog);

Brian Mitchell

unread,
Aug 3, 2010, 11:07:32 AM8/3/10
to nod...@googlegroups.com
While I somewhat agree here the use of __proto__ really bugs me.
Wrapping up an Object.create type of call seems to be a better idea
that allows portability to browsers for some libraries. The other
problem is that the docs don't really specify which objects require
any specific initialization with a super constructor and which just
need prototypes.

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.

Aaron Heckmann

unread,
Aug 3, 2010, 12:16:09 PM8/3/10
to nod...@googlegroups.com
On Tue, Aug 3, 2010 at 11:07 AM, Brian Mitchell <bina...@gmail.com> wrote:
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.

And that's why I think it's time to promote it to the public api. We're creating larger and larger projects built upon Node cores foundation and I see the need to at least "recommend" sys.inherits in the docs. There are some Class implementations out there that don't play well with Node. Let's at least guide devs in the right direction whether it be sys.inherits, TJs suggestion, or something similar.

Marco Rogers

unread,
Aug 3, 2010, 1:50:24 PM8/3/10
to nodejs
-1 to using __proto__ just cause it's not standard. It won't break in
IE but it also fails some of the asserts. Haven't tested the
sys.inherits implementation in browser. Probably has some issues as
well. But I would think that people using sys.inherits aren't
concerned about portability at least at this stage.

After thinking about this further, I still think we should do
something about sys.inherits. But it's also a slippery slope to start
"recommending" approaches to core programming paradigms. Aaron, can
you elaborate on the problems you've seen with Class implementations
in node? I'm curious. People should use what they want and if it
causes problems in node, they should fix it or point to how it can be
fixed in node. As soon as there's a "blessed" version, there will be
less incentive for people to do that.

:Marco

On Aug 3, 12:16 pm, Aaron Heckmann <aaron.heckm...@gmail.com> wrote:

anders conbere

unread,
Aug 3, 2010, 2:05:48 PM8/3/10
to nod...@googlegroups.com
I know there's a few of us (in a minority) that right code that runs
in both Node and on browsers. The more that external libs depend on
difficult to include behaviors (sys.inherits is one that I've replaced
when porting a number of node internal modules to run in the browser)
the more work we have to do to fight it.

This could easily be handled by a Node compatibility layer but I just
haven't bothered to get there.

~ Anders

Brian Mitchell

unread,
Aug 3, 2010, 2:21:53 PM8/3/10
to nod...@googlegroups.com
On Tue, Aug 3, 2010 at 14:05, anders conbere <acon...@gmail.com> wrote:
> I know there's a few of us (in a minority) that right code that runs
> in both Node and on browsers. The more that external libs depend on
> difficult to include behaviors (sys.inherits is one that I've replaced
> when porting a number of node internal modules to run in the browser)
> the more work we have to do to fight it.
>
> This could easily be handled by a Node compatibility layer but I just
> haven't bothered to get there.

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 Heckmann

unread,
Aug 3, 2010, 2:36:25 PM8/3/10
to nod...@googlegroups.com
On Tue, Aug 3, 2010 at 1:50 PM, Marco Rogers <marco....@gmail.com> wrote:
Aaron, can
you elaborate on the problems you've seen with Class implementations
in node?  I'm curious. 

A while back in a previous version of Express I toyed with making Express.Server inherit from http.Server using the bundled Class.js (no longer bundled) and ran into problems with it. Class.js works great with the classes it generates (inheritance, extension, etc) but it doesn't naturally work well with classes that weren't created with it, like http.Server.

inimino

unread,
Aug 3, 2010, 4:13:42 PM8/3/10
to nod...@googlegroups.com
On 2010-08-03 12:05, anders conbere wrote:
> I know there's a few of us (in a minority) that right code that runs
> in both Node and on browsers. The more that external libs depend on
> difficult to include behaviors (sys.inherits is one that I've replaced
> when porting a number of node internal modules to run in the browser)
> the more work we have to do to fight it.

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.

--
http://inimino.org/~inimino/blog/

Isaac Schlueter

unread,
Aug 3, 2010, 4:59:12 PM8/3/10
to nod...@googlegroups.com
sys.inherits is a reusable that is used in many places in nodejs. It
is only exposed because that's the most expedient way to make it
reusable throughout node-core.

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

Brian Mitchell

unread,
Aug 3, 2010, 5:12:55 PM8/3/10
to nod...@googlegroups.com
On Tue, Aug 3, 2010 at 16:59, Isaac Schlueter <i...@izs.me> wrote:
> sys.inherits is a reusable that is used in many places in nodejs.  It
> is only exposed because that's the most expedient way to make it
> reusable throughout node-core.

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.

Marco Rogers

unread,
Aug 3, 2010, 5:24:04 PM8/3/10
to nodejs
+1

Also, I'm always a little confused by people equating sys.inherits
with classical inheritance. It does no such thing. It deals with
named constructors and uses vanilla javascript prototype chaining.
All it does is add the convenience of super_ which you don't even have
to use. The nice thing about sys.inherits is it uses Object.create to
set the prototype instead of sub.prototype = super.prototype. That's
the half-ass way I see happening in the wild which results in trashing
your prototype chain when you try to add additional methods to
sub.prototype. Using Object.create essentially becomes equivalent to
TJs method without using non-standard properties.

I may be getting something wrong though, so if someone wants to school
me, please do.

But I think the real problem here is that sys.inherits *feels*
magical. A new name may help with this. Another option is Aaron's
idea of a "recommended" page in the docs. It could literally display
the full source of sys.inherits so people understand that there is no
magic happening. They can use it without apprehension or they can
decide it's not what they need and use something else. And from that
point forward when they see it in other code, it won't feel like such
a black box.

:Marco

Isaac Schlueter

unread,
Aug 3, 2010, 5:46:41 PM8/3/10
to nod...@googlegroups.com
Oh, sorry, I thought we were debating whether or not it should be removed.

> 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

Brian Mitchell

unread,
Aug 3, 2010, 5:52:49 PM8/3/10
to nod...@googlegroups.com
On Tue, Aug 3, 2010 at 17:46, Isaac Schlueter <i...@izs.me> wrote:
> Don't people just do Function#toString in the repl for everything they use?

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.

Aaron Heckmann

unread,
Aug 3, 2010, 6:10:05 PM8/3/10
to nod...@googlegroups.com
A newcomer is not likely to jump into the repl and .toString everything, especially sys.inherits, since they won't know it even exists. 

For me this is a couple things:

1) stop hiding sys.inherits by excluding it from the docs and 
2) lowering the barrier for newcomers. 

Devs are using sys.inherits whether it's internal or not. Let's embrace it's use and add it to the docs with an explaination so newcomers can decide if its for them or not. 

Nathan

unread,
Aug 3, 2010, 9:14:23 PM8/3/10
to nodejs
I would prefer for it to be kept as it is now. I don't think its use
should be encouraged in 3rd party libraries. Use it throughout node
core, who cares. However, Object.create style inheritance or some
other non-node-centric style of inheritance should be encouraged in
3rd party libs.
> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > 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>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> --
> Aaronhttp://clickdummy.net
Reply all
Reply to author
Forward
0 new messages