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
change lines
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.
etc.
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> of
all things.*"
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.
Greet :)
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
> "classes" in JavaScript.
> 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%
> compatible with raw JavaScript "classes".
> 3.2 Please show a minimal example or give a link which will describe it
> more.
> 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
>>
>> greets
>>
>>
>> Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
>>>
>>> Thanks for answer, everyone, it is pleasant :-)
>>>
>>> To just clear my point. I understand why raw JavaScript inheritance
>>> often is preferred, no need to know what "Class" does for example. Simply
>>> speaking can every single JavaScript programmer see what is going on. But
>>> 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
>>> does not use any advanced JavaScript, all serious developers should
>>> 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.
>>>>
>>>> Read and write a lot of idiomatic JavaScript and you'll quickly get
>>>> 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.
>>>>
>>>> Either way, JavaScript is really fun so go write cool things and enjoy
>>>> it :)
>>>>
>>>
--
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 protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
