"And in which way can you skip this in normal prototype inheritance?"
using this.constructor.prototype.getText in the instance methods (also the
non-standard shorthand this.__proto__ in code, that can be
vendor-specific). in this case you can just assign another object as
prototype and the code works, even at runtime. Of cause you could do this
in your gist too, but you didn't. and TJ is right. Editors are good at the
job to reduce typing and insert code patterns without changing the
semantics. :) your tool, the helper, change it, not in it's implementation,
but in it's usage, thats the main point. It hides the nature. JS knows and
uses different extension patterns and your tool introduces (at usage point)
the wrong semantic. as i said, inheritance is not the only way to reuse
code and its valid even more for JS, where mixins and method borrowing are
common technics. so as user i see your Class helper and do not know at this
point, how it handles code re-usage. thats it.
Am Montag, 5. November 2012 20:07:30 UTC+1 schrieb Fredrik O:
>
> Den måndagen den 5:e november 2012 kl. 10:01:58 UTC+1 skrev greelgorke:
>>
>> 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").
>>
>
> It reduces the amount of code you must type down:
>
> var Name = helper({
> method1: function() {
> },
> method2: function() {
> },
> //..
> });
>
> vs
>
> function Name() {
> }
> Name.prototype.method1 = function() {
> };
> Name.prototype.method2 = function() {
> };
> //...
> Without the helper, you must repetitive times write: "Name.prototype".
> You can of course assign it in the function using this, but it is bad
> practice and has poor performance. And as soon you start to use any helper
> variable and function, do you use code you argue against.
>
> 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.
>>
>
> I am not a big fan of inheritance nor OO, but sure can it be great, same
> as multiple inheritance.
>
--
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
