@Point of reading: well, you might wander, but i developed a superability.
i's named textscanning and is applyable to common patterns. advertisement
industry try to break patterns to get you aware of the ad. thats the
difference. if i see a prototypal based pattern, i just scan over it and
look over the Constructor.prototype sentence as long it's always the same.
BUT at the end its more a matter of taste than anything else.
@Example: I was too fast with my saying, i admit that. take a look at this:
function Base(){}
Base.prototype.t = function(){return 'BASE'}
function Sub(){}
Sub.prototype = new Base()
s = new Sub()
s.t() //'BASE'
Sub.prototype.t = function(){return 'SUB'}
s.t() //'SUB'
Sub.prototype.t = function(){return 'SUB'+
Sub.prototype.constructor.prototype.t()}
s.t() //'SUBBASE'
function Base2(){}
Base2.prototype.t = function(){return 'BASE2'}
Sub.prototype = new Base2()
s.t() // 'SUBBASE2'
at the end, both variants has their limitations. limitation in this example
is the long property chain lookup to get the implementation of the
prototype. in v8 you can use this.__proto__ instead of
Sub.prototype.constructor.prototype, but __proto__ is non-standard. another
disadvantage of this approach is, that the instances created before
reassignment of Sub.prototype still link to old prototype-object. so if we
continue the above example:
Sub.prototype.t = function(){return 'SUBSUB'}
s.t() //still returns SUBBASE2 not SUBSUB
for me, personaly, this is another issue thad drives me away from
inheritance as code re-usage strategy. To many indirections and pitfalls.
code sharing via simple prototype is ok, since it's prefered by v8 for
optimisations. but i wouldn't reuse/extend objects with it if i don't have
to.
@is-a/has-a: it's the point for inheritance. it's is rarely really needed
to establish is-a relation. It's about Identity or about protection of a
library as a replacement for interface types? both are not really safe
viable with instanceof, because constructor property is public and
assignable. If i have to establish is-a relation, i'd rather do this via
simple property than prototypes. in fact usage of instanceof is considered
as smell and should be avoided anyway.
greet
Am Dienstag, 6. November 2012 19:32:08 UTC+1 schrieb Fredrik O:
>
> Thanks for answer, everyone. It is decent of you to take time to answer me.
>
> Raynos:
>
> First of was you not allowed to use helpers, but because you did will i
> show you a shorter alternative:
>
> var Name = myHelper({
> //...
> });
>
> Tada. No more typing and it does exactly the same thing as your example.
>
>
> tjholowaychuk:
>
> I know editors can remove must of those typing, but as soon as your brain
> sees it, will it
> process it and therefore take energy. It is the inconvenient truth of all
> humans. The advertising industry uses it
> all the time. Because of this, even if you a perfect editor those will fix
> everything for you will it always be preferable to
> have less code, as long as the code does not add any complexity, as it
> does not if you ask me.
>
> greelgorke:
>
> Same answer applies to you as tjholowaychuk, so you can read what I wrote
> to her/him as well. Your proposal "this.constructor.prototype.getText"
> does not work by the way, so it should be graceful if you can show a
> minimal code example. And if it exist would it be OK to use it in the
> helper method as well, because it should be 100% compatible with pure
> JavaScript inheritance.
>
> Alexey Petrushin:
>
> You are using mixins, nothing wrong with it, sometimes is it preferred to
> actually inherit from another object/function to gain the "is-a" relation.
> With mixins can you only gain the relation "has-a". It is not the same
> thing as the relation "is-a". The "instanceof" operator will not work only
> because you add some methods to a prototype, as it must if it is a "is-a"
> relation. You can however emulate it pretty good do I believe with correct
> instanceof behaviour.
>
>
> To all:
>
> The largest disadvantages the helper class has it is uses the arguments
> parameter to forward all calls. It will prevent huge optimizations if V8 is
> not smart enough.
>
>
--
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
