1. Yes, it is, but this word is overburden with a bunch of semantics and
introduces the classical OO mindset immediately. But, it's your helper,
name it like you wish and deal the with the consequences :)
3. I guess "helpful" is a matter of flavor and familiarity. i don't see the
need to type down "classes" in js, may be thats the point.
3.1 a helper in a sense of DRY have to reduce amount of code. now instead
of typing down the prototype, constructor etc, you have to pass objects,
that's just anouther side of the same verbosity and it changes the
semantics here a bit ("i use classical mindset now").
3.2 your gist: to change the prototype of the Derived2 class you have to
47: call to "base" constructor
51: call to getText from "base" proto, simulating super.getText
57: Change property baseClass
to change prototype at runtime you have to do even more, like replacing the
getText property with a new function with the call to the new prototype.
4. This is really a topic with potential to produce a next world war. there
are so many definitions of OO and most of them are near by a dogma. OO is
about Objects, objects encapsulate and hide internal data/state and offer
public API to manipulate this data. Allan Key said in 2003:
"*OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme LateBinding<http://c2.com/cgi/wiki?LateBinding
No word of classes anymore. Classes are state of the art to define Types in
OO, but its not the only way to do that. Inheritance is a preferred way to
share and reuse Code in OO, but it's not the only way, "Favor Composition
over Inheritance" is one of OO-Design Principles, because it's introduces
looser coupling than the coupling offered by classical inheritance.
@Alexey: it's an easy way, becaue in most OO languages classical
Inheritance is supported by the runtime. it offers all the clutter for
dynamic lookup of methods/functions. But you could handle it also perfectly
easy by mixing, borrowing, decorating/wrapping, curring etc. all it misses
is the runtime support for such constructs. fortunately there are libs
which can help.
In fact, if you really think about it, classical inheritance is nothing
more than composition with tight coupling and automatic delegate
resolution. JS prototypal inheritance allows loose coupling, and thats it
what it make so powerful.
Am Freitag, 2. November 2012 18:33:55 UTC+1 schrieb Fredrik O:
Thanks for answer, greelgorke.
1. It is just a name of a variable.
2. I agree.
3. It only does what every developer must type down anyway to implement
3.1 It don´t need to be significant shorter, but it is indeed shorter and
more readable if you ask me. The purpose was never to do any fancy stuff
like many others "Class" helpers, it was never the idea, but to automate
those things you must do anyway. The returned object should always be 100%
3.2 Please show a minimal example or give a link which will describe it
4. Wrong, OOP is about classes/objects and this is exactly what the helper
function is about, by creating a minimal "class". A "class object" in the
OOP world is anyway just a bunch of methods and a set of features, which I
prefer to see separate.
Den fredagen den 2:e november 2012 kl. 17:16:48 UTC+1 skrev greelgorke:
1. do not use Class word :)
2. it's ok to use helpers, DRY is key
3. your helper doesn't look very helpful for me
3.1 usage of your helper doesn't seem significant shorter than the pure
way to write this things down, looks even more verbose to me, without
serving readability (TJ's point)
3.2 everywhere Hardcoded reference to the "super"-Contsructor function
-> changing the inheritance chain is more complicated at development time,
even harder or impossible at runtime.
4. it's not lightweight OOP but lightweight inheritance. OO is more than
inheritance (in fact it doesn't even need inheritance)
my opinion from the first sight
Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
Thanks for answer, everyone, it is pleasant :-)
often is preferred, no need to know what "Class" does for example. Simply
now to my point.
Say I am writing many small modules. Those modules should only export
some function who gives some type of functionality. The user of those
modules only care about the functionality and how it behaves, not how it is
actually implemented. Say now it takes somewhat shorter time when I use a
helper function than it would without it, why should I not use then?
The "dependency" is included in the source, so every developer can fast
and easily check it up. The generated function will have the same
performance as the handwritten function probably and it will increase the
readability of the source code somewhat. The function helper itself
understand it and no fancy stuff is added. So why is it not preferred to
use a helper function in those situations? I cannot really get it when
those advantages is applied.
Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
I agree with Isaac,
Build classical function helpers as a learning experience, which which
will show you that you don't need them.
over (and actually start to like) the syntax of "Constructor.prototype.*".
I personally fought this for much longer than necessary. Once you get over
it, hundred-line object literals (including the popular "module" pattern)
will start to look extremely obtuse and superfluous.
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en?hl=en