inheritance - prototype injection
atwork8
I've been trying out different ways of making javascript inheritance a
bit easier and less error prone. I've set up some tests to see if
performance wise I was heading in the right direction. For anybody
that is interested these can be found on the link below:
http://www.projectcss.net/inheritance/
Of the implementations so far I really like the following "j3Class" as
it's the fastest, simplest, and avoids the DontEnum bug:
http://www.projectcss.net/inheritance/j3Class-Syntax/
Now my question is, does this prototype injection technique come at a
cost? I'm assuming there must be some problem with it otherwise it
would be used more, however, from my tests it doesn't appear to have
any performance issues. So what am I missing?
Thanks for any help,
Reiss
Thomas 'PointedEars' Lahn
> Of the implementations so far I really like the following "j3Class" as
> it's the fastest, simplest,
No, it certainly isn't.
> and avoids the DontEnum bug:
There is no "DontEnum bug".
> http://www.projectcss.net/inheritance/j3Class-Syntax/
>
> Now my question is, does this prototype injection technique come at a
> cost? I'm assuming there must be some problem with it otherwise it
> would be used more, however, from my tests it doesn't appear to have
> any performance issues. So what am I missing?
The `init' property is already used (and cannot be reused), it requires a
lot of closures (which is asking for trouble in IE/MSHTML), and it requires
Function.prototype.apply() which requires JScript 5.5. When a simple
constructor and maybe an additional method to set up the prototype chain
would have sufficed.
Exactly the same basic mistakes at inheritance that Sam Stephenson made
years ago with introducing Prototype.js 1.0.
PointedEars
atwork8
> No, it certainly isn't.
I'm not sure what bit you are referring to with the above statement?
If was to do with simplicity then It's only 12 lines of code. It can't
be that complicated lol
> There is no "DontEnum bug".
There is an enumeration bug with IE's JScript, so not sure what you
mean?
> The `init' property is already used (and cannot be reused), it requires a
> lot of closures (which is asking for trouble in IE/MSHTML), and it requires
> Function.prototype.apply() which requires JScript 5.5. When a simple
> constructor and maybe an additional method to set up the prototype chain
> would have sufficed.
The init property is just acting as a constructor, and if required can
use and override its parent constructor. It uses one closure per class
definition which I don't think is a lot. JScript 5.5 has been around
for years so I'm not sure why that is relevant? And it doesn't require
"Function.prototype.apply()", you're free to call parent methods
anyway you like, "base" is provided for simplicity and the reasons
below.
I've tried to keep the mechanics and syntax as pure and as natural as
possible e.g.
"p.punch" is the same as "Boxer.prototype.punch" which is the native
way.
"base.punch.call(this,iPunchCount + 100)" is the same as
"Fighter.prototype.punch.call(this,iPunchCount + 100)" again this is
the native way of calling parent methods, how else would you call
parent methods?
By doing the above there is less typing and therefore less margin for
errors, and less bytes. Constructor names aren't hard coded into class
specs allowing for easier code refactoring should you choose to rename
things. It takes care of the prototype chain, and I personally think
it is a lot nicer to read and code. And by adding this slight
abstraction it allows for additional helper methods such as
Implements, which I'm all for.
For all the above benefits, you still have performance near native
function C(){}; C.prototype.method = something... I don't think it's
too bad lol
Thanks,
Reiss
RobG
> Hi PointedEars,
>
> > No, it certainly isn't.
>
> I'm not sure what bit you are referring to with the above statement?
> If was to do with simplicity then It's only 12 lines of code. It can't
> be that complicated lol
If you hadn't trimmed the part Thomas was replying to, you might see
that he could be referring to the "it's the fastest" claim.
>
> > There is no "DontEnum bug".
>
> There is an enumeration bug with IE's JScript, so not sure what you
> mean?
You addressed the issue with toString, but what about valueOf?
var o = {toString: 'toString', valueOf: 'valueOf'};
alert(
'toString enumerable? ' + o.propertyIsEnumerable('toString') +
'\nvalueOf enumerable? ' + o.propertyIsEnumerable('valueOf')
);
[...]
> By doing the above there is less typing and therefore less margin for
> errors, and less bytes. Constructor names aren't hard coded into class
> specs allowing for easier code refactoring should you choose to rename
> things. It takes care of the prototype chain, and I personally think
> it is a lot nicer to read and code. And by adding this slight
> abstraction it allows for additional helper methods such as
> Implements, which I'm all for.
>
> For all the above benefits, you still have performance near native
> function C(){}; C.prototype.method = something... I don't think it's
> too bad lol
I think the real point is that while javascript can be used to imitate
the OO paradigms of other languages to some extent[1], capable and
experienced javascript programmers have realised that it isn't
necessary in the vast majority of cases, if ever[2].
The module pattern[3] is usually sufficient and, when used as a
constructor, provides similar benefits to class-based patterns without
the prototype dance.
1. <URL: http://javascript.crockford.com/inheritance.html >
2. "I have learned to fully embrace prototypalism,
and have liberated myself from the confines of
the classical model." - Douglas Crockford
<URL: http://javascript.crockford.com/prototypal.html >
Note that Crockford's prototype dance in the begetObject
method has been discussed here and can be improved.
3. Google it, there are lots of blogs on it, here's one:
<URL: http://yuiblog.com/blog/2007/06/12/module-pattern/ >
--
Rob
kangax
> atwork8 wrote:
[...]
>> and avoids the DontEnum bug:
>
> There is no "DontEnum bug".
"JScript DontEnum Bug" is actually explained about pretty clearly in MDC.
<URL: https://developer.mozilla.org/en/ECMAScript_DontEnum_attribute>
[...]
--
kangax
kangax
> Hi all,
>
> I've been trying out different ways of making javascript inheritance a
> bit easier and less error prone. I've set up some tests to see if
> performance wise I was heading in the right direction. For anybody
> that is interested these can be found on the link below:
>
> http://www.projectcss.net/inheritance/
>
> Of the implementations so far I really like the following "j3Class" as
> it's the fastest, simplest, and avoids the DontEnum bug:
>
> http://www.projectcss.net/inheritance/j3Class-Syntax/
[...]
| var j3 = {
| version: '0.0.4',
| mixin: function(oChild,oParent) {
| for(var sProp in oParent) {
| oChild[sProp] = oParent[sProp];
| }
| //jscript enumeration fix for 'toString' only - DontEnum bug
| if(oParent.hasOwnProperty('toString')) {
| oChild['toString'] = oParent['toString'];
| }
1) What about the rest of `Object.prototype` properties - `valueOf`,
`toLocaleString`, etc.
2) There's no reason to perform this enumeration when a bug is not
present. Why not test for it once and store result as a boolean, or even
better - "fork" `mixin` function.
3) `Object.prototype.hasOwnProperty` is missing in (not so) older Safari
(2.x). It might be a good idea to use a custom version of
`hasOwnProperty` which would delegate to
`Object.prototype.hasOwnProperty` when available and use some other
simulation otherwise.
4) Accessing `hasOwnProperty` as a property of `oParent` object (when
calling it) might conflict with direct, same-named, property of that
object. Using `Object.prototype.hasOwnProperty.call(oParent,
'toString')` should help to avoid such conflict.
| },
| extend: (function() {
| function F() { };
| return function(oParent) {
| F.prototype = oParent;
| return new F();
| };
| })(),
Good to see `F` not being recreated every time `extend` is called : )
| _implement: function(obj) { j3.mixin(this.prototype,obj); },
| Class: function(oParent,fClass) {
| if(fClass) {
| fClass.prototype = this.extend(oParent.prototype);
| fClass(fClass.prototype,oParent.prototype);
| } else {
| fClass = oParent;
| fClass(fClass.prototype);
| }
| var c = fClass.prototype.init;
| c.prototype = fClass.prototype;
| c.prototype.constructor = c;
| c.prototype._spec = fClass;
| try{return c;}finally{c=null;}
I think IE6 doesn't support try/finally (contrary to try/catch/finally).
You might want to check that.
| }
| }
I probably missed something else.
--
kangax
atwork8
> If you hadn't trimmed the part Thomas was replying to, you might see
> that he could be referring to the "it's the fastest" claim.
Exactly, or he could have been referring to simplicity, or both, hence
why I asked. "No, it certainly isn't" doesn't say much. And if it was
about performance, run the tests I have created and you'll see it out
performs the rest (excluding wr, where the performance is pretty
even).
> > > There is no "DontEnum bug".
>
> > There is an enumeration bug with IE's JScript, so not sure what you
> > mean?
>
> You addressed the issue with toString, but what about valueOf?
>
> var o = {toString: 'toString', valueOf: 'valueOf'};
>
> alert(
> 'toString enumerable? ' + o.propertyIsEnumerable('toString') +
> '\nvalueOf enumerable? ' + o.propertyIsEnumerable('valueOf')
> );
I should have removed the mixin part to avoid confusion. That is the
point of my post. If you inject the prototype reference then there is
no need for this type of thing. If you check the syntax page above
you'll see the example doesn't use mixin yet still inherits the
"toString" attribute in IE.
> I think the real point is that while javascript can be used to imitate
> the OO paradigms of other languages to some extent[1], capable and
> experienced javascript programmers have realised that it isn't
> necessary in the vast majority of cases, if ever[2].
>
> The module pattern[3] is usually sufficient and, when used as a
> constructor, provides similar benefits to class-based patterns without
> the prototype dance.
>
> 1. <URL:http://javascript.crockford.com/inheritance.html>
>
> 2. "I have learned to fully embrace prototypalism,
> and have liberated myself from the confines of
> the classical model." - Douglas Crockford
> <URL:http://javascript.crockford.com/prototypal.html>
>
> Note that Crockford's prototype dance in the begetObject
> method has been discussed here and can be improved.
>
> 3. Google it, there are lots of blogs on it, here's one:
> <URL:http://yuiblog.com/blog/2007/06/12/module-pattern/>
>
> --
> Rob
I'm not trying to imitate anything, I trying to make what Javascript
has a bit nicer to use. My response to PointedEars explains this in
some detail. I'm aware of the module pattern but it is more of a
singleton pattern and doesn't lend itself well to inheritance.
Thanks for the links but I have read them before. If you look on the
syntax link above you'll see that I actually use a more efficient
version of the beget function.
Thanks,
Reiss
atwork8
Thanks for the constructive feedback, it's appreciated. And thanks for
the enumeration bug confirmation.
Apologies though, I should have removed the mixin function to avoid
any confusion. In the example used on the syntax link above you'll see
that IE inherits the "toString" attribute without using the mixin
function, which is what I was asking about: Does injecting the
prototype reference like this (to avoid enumeration problems) have any
downsides? The performance wouldn't indicate this as it's faster than
the rest.
Thanks again,
Reiss :o)
Thomas 'PointedEars' Lahn
> Hi PointedEars,
This is public Usenet, not private e-mail.
>> No, it certainly isn't.
>
> I'm not sure what bit you are referring to with the above statement?
I don't know what you are sure about, stop asking such stupid questions.
However, I'm pretty sure that you are unable to read and quote properly.
> If was to do with simplicity then It's only 12 lines of code. It can't
> be that complicated lol
Parse error. (And, do you think that laughing about your own statements in
the same sentence makes you look rather smart here?)
>> There is no "DontEnum bug".
>
> There is an enumeration bug with IE's JScript, so not sure what you
> mean?
There might be implementation-dependent behavior in JScript that could be
called a bug. But why would that be relevant *for inheritance*?
>> The `init' property is already used (and cannot be reused), it requires a
>> lot of closures (which is asking for trouble in IE/MSHTML), and it requires
>> Function.prototype.apply() which requires JScript 5.5. When a simple
>> constructor and maybe an additional method to set up the prototype chain
>> would have sufficed.
>
> The init property is just acting as a constructor,sure
The language has constructors already; there is no need to reinvent them in
a less inefficient, less compatible, more error-prone and harder-to-maintain
way.
> and if required can use and override its parent constructor.
Non sequitur.
> It uses one closure per class definition
There are still no classes.
> which I don't think is a lot.
It uses a lot more that you fail to see.
> JScript 5.5 has been around for years so I'm not sure why that is
> relevant?
Windows 2000 will cease to be supported by Microsoft on 2010-04-21 or later
(depending on whether there will be a next service pack). There are
applications using MSHTML 5.5 besides Web browsers.
> And it doesn't require "Function.prototype.apply()",
Yes, it does. Function.prototype.apply() cannot be emulated.
> you're free to call parent methods anyway you like,
It is not the parent method that is called with Function.prototype.apply()
but the init() method. Don't you understand your own code?
> "base" is provided for simplicity and the reasons below.
No doubt about that.
> I've tried to keep the mechanics and syntax as pure and as natural as
> possible e.g.
But you didn't. The pure and natural syntax of prototype-based inheritance
in these prototype-based object-oriented programming languages is very
well-documented, and it differs very much from your approach.
> "p.punch" is the same as "Boxer.prototype.punch" which is the native
> way.
You don't know what you are talking about.
> "base.punch.call(this,iPunchCount + 100)" is the same as
> "Fighter.prototype.punch.call(this,iPunchCount + 100)"
If Function.prototype.call() is supported. (However, this is a method that
can be rather efficiently emulated for primitive values.)
> again this is the native way of calling parent methods,
> how else would you call parent methods?
There are other ways, discussed at great length before.
> By doing the above there is less typing
Ahh, the jQuery neophytes' non-argument. I wondered when you would try
using that.
> and therefore less margin for errors,
Nonsense. The margin for errors has merely shifted to within the
implementation of the approach which cannot be fixed just as easily once a
sufficient amount of code has been written based on it. Prototype.js and
jQuery tell.
> and less bytes.
When you've grown up you'll probably recognize that size is not everything.
> Constructor names aren't hard coded into class specs
There are no classes.
> allowing for easier code refactoring should you choose to rename
> things. It takes care of the prototype chain, and I personally think
> it is a lot nicer to read and code.
Opinions are like ass-holes; everybody has one.
-- Larry Flynt
> And by adding this slight abstraction it allows for additional helper
> methods such as Implements, which I'm all for.
All of that can be done using a much simpler pattern.
> For all the above benefits, you still have performance near native
> function C(){}; C.prototype.method = something...
There are ways to create prototype objects that don't involve consecutive
assignments to properties of prototype objects.
> I don't think it's too bad lol
^^^
It appears you deserve what you get. (Whatever you take, take less of it.)
Anyway, why did you post here in the first place? To be padded on the back
for which great invention that you made? You can be certain that it is
mostly inefficient hard-to-maintain junk instead, repeating the mistakes of
many others before you. Congratulations.
PointedEars
atwork8
though you'll understand what I'm getting at, by injecting a prototype
reference you could eliminate the need for a mixin function. I'll post
up a better example of this technique later.
Thanks,
Reiss
atwork8
post ever" award, and maybe even "bestest javascript discovery of the
past decade". Seriously though, I've simply asked a question on a
newsgroup and I'm not sure why that merits such a harsh response from
yourself? If my response to you was offensive in any way then please
accept my apology.
> I don't know what you are sure about, stop asking such stupid questions.
> However, I'm pretty sure that you are unable to read and quote properly.
"Of the implementations so far I really like the following "j3Class"
as
it's the fastest, simplest,"
You answered "No, it certainly isn't." to the above quote. I asked
what bit you were referring to, what is the problem?
> > If was to do with simplicity then It's only 12 lines of code. It can't
> > be that complicated lol
> Parse error. (And, do you think that laughing about your own statements in
> the same sentence makes you look rather smart here?)
Nope, was just trying to keep the post upbeat.
> >> There is no "DontEnum bug".
>
> > There is an enumeration bug with IE's JScript, so not sure what you
> > mean?
>
> There might be implementation-dependent behavior in JScript that could be
> called a bug. But why would that be relevant *for inheritance*?
So if there is a "implementation-dependent behavior" "that could be
called a bug", and you knew exactly what I meant, why bother posting
"There is no "DontEnum bug"?
> > The init property is just acting as a constructor,sure
>
> The language has constructors already; there is no need to reinvent them in
> a less inefficient, less compatible, more error-prone and harder-to-maintain
> way.
>
> > and if required can use and override its parent constructor.
>
> Non sequitur.
>
I'm glad you agree they are more efficient, which isn't always about
speed. If you have any valid reasons for your other comments It would
be good to hear them?
> > It uses one closure per class definition
>
> There are still no classes.
Obviously there are no classes (yet), but you understand what I mean.
> > which I don't think is a lot.
>
> It uses a lot more that you fail to see.
>
> > JScript 5.5 has been around for years so I'm not sure why that is
> > relevant?
>
> Windows 2000 will cease to be supported by Microsoft on 2010-04-21 or later
> (depending on whether there will be a next service pack). There are
> applications using MSHTML 5.5 besides Web browsers.
When did I mention what I intended to support? And the major
javascript libraries used by thousands don't seem to share your
concerns.
> > And it doesn't require "Function.prototype.apply()",
>
> Yes, it does. Function.prototype.apply() cannot be emulated.
No it doesn't, simply pass in the arguments as you would with any
constructor and use Parent.init.call(this,arg1,ag2,ag3) or use
whatever method you want to call another function with the correct
scope.
>
> > you're free to call parent methods anyway you like,
>
> It is not the parent method that is called with Function.prototype.apply()
> but the init() method. Don't you understand your own code?
In the example I call the parent function "init" using
"base.init.apply" this could also have been "base.init.call" or
another method that provides the correct scope.
> > "base" is provided for simplicity and the reasons below.
>
> No doubt about that.
>
> > I've tried to keep the mechanics and syntax as pure and as natural as
> > possible e.g.
>
> But you didn't. The pure and natural syntax of prototype-based inheritance
> in these prototype-based object-oriented programming languages is very
> well-documented, and it differs very much from your approach.
Yes it is well documented. The syntax is different but the mechanics
are the same. I'm not using this.parent(), this.$super(), etc. I'm
still using the native way of calling parent methods. I'm not looping
through properties and copying them from one object to another, I'm
adding them directly to the prototype e.g.
Constructor.prototype.method How does that differ "very much"?
> > "p.punch" is the same as "Boxer.prototype.punch" which is the native
> > way.
>
> You don't know what you are talking about.
In what way?
> > "base.punch.call(this,iPunchCount + 100)" is the same as
> > "Fighter.prototype.punch.call(this,iPunchCount + 100)"
>
> If Function.prototype.call() is supported. (However, this is a method that
> can be rather efficiently emulated for primitive values.)
Like I have said, you can use ANY way you want. I prefer call() and
apply().
> > again this is the native way of calling parent methods,
> > how else would you call parent methods?
>
> There are other ways, discussed at great length before.
>
Great. Then as I have said you are not tied to any particular way. The
native call() and apply() work great.
>
> > By doing the above there is less typing
>
> Ahh, the jQuery neophytes' non-argument. I wondered when you would try
> using that.
>
> > and therefore less margin for errors,
>
> Nonsense. The margin for errors has merely shifted to within the
> implementation of the approach which cannot be fixed just as easily once a
> sufficient amount of code has been written based on it. Prototype.js and
> jQuery tell.
If you write no code you can write no errors. If you write more code
you can write more errors. Simple. What would need fixed, it is using
a constructor and prototype, that is basic javascript.
> > and less bytes.
>
> When you've grown up you'll probably recognize that size is not everything.
Less with the patronising, it's pretty pathetic.
> > Constructor names aren't hard coded into class specs
>
> There are no classes.
Obviously there are no classes (yet), but you understand what I mean.
> > allowing for easier code refactoring should you choose to rename
> > things. It takes care of the prototype chain, and I personally think
> > it is a lot nicer to read and code.
>
> Opinions are like ass-holes; everybody has one.
> -- Larry Flynt
True
> > And by adding this slight abstraction it allows for additional helper
> > methods such as Implements, which I'm all for.
>
> All of that can be done using a much simpler pattern.
I fail to see the complexity in this?
> > For all the above benefits, you still have performance near native
> > function C(){}; C.prototype.method = something...
>
> There are ways to create prototype objects that don't involve consecutive
> assignments to properties of prototype objects.
In what I am trying to achieve (see the other implementations on the
test page) it is extremely fast. If you have an alternative
implementation where the performance if significantly better then I
would like to see it? I would also add it to the test cases for
others, showing your different approach.
> > I don't think it's too bad lol
>
> ^^^
> It appears you deserve what you get. (Whatever you take, take less of it.)
Again less with the patronising, it's pretty pathetic.
> Anyway, why did you post here in the first place? To be padded on the back
> for which great invention that you made? You can be certain that it is
> mostly inefficient hard-to-maintain junk instead, repeating the mistakes of
> many others before you. Congratulations.
>
> PointedEars
See the start of this reply. Could you please provide some evidence to
support your opinion "that it is
mostly inefficient hard-to-maintain junk instead"? I fail to see how
this is the case.
Hopefully I haven't offended you in this reply as it is NOT my
intention.
Thanks,
Reiss
Thomas 'PointedEars' Lahn
> @PedanticEars - You got me! I was hoping to get the "most awesomest
> post ever" award, and maybe even "bestest javascript discovery of the
> past decade". Seriously though, I've simply asked a question on a
> newsgroup and I'm not sure why that merits such a harsh response from
> yourself? If my response to you was offensive in any way then please
> accept my apology.
No. You are already rated a luser, and every new sentence you write
confirms that you are. "@PedanticEars"? Get a life.
>> I don't know what you are sure about, stop asking such stupid questions.
>> However, I'm pretty sure that you are unable to read and quote properly.
>
> "Of the implementations so far I really like the following "j3Class"
> as it's the fastest, simplest,"
>
> You answered "No, it certainly isn't." to the above quote. I asked
> what bit you were referring to, what is the problem?
You did not quote what you were referring to which could have left the
impression that I was not referring to which I was replying, but I did.
As for what I was referring to, it was apparently obvious to everyone
else that my "it isn't" referred to your "it's the fastest, simplest".
>>> If was to do with simplicity then It's only 12 lines of code. It can't
>>> be that complicated lol
>> Parse error. (And, do you think that laughing about your own statements in
>> the same sentence makes you look rather smart here?)
>
> Nope, was just trying to keep the post upbeat.
My, you are such a luser.
>>>> There is no "DontEnum bug".
>>> There is an enumeration bug with IE's JScript, so not sure what you
>>> mean?
>> There might be implementation-dependent behavior in JScript that could be
>> called a bug. But why would that be relevant *for inheritance*?
>
> So if there is a "implementation-dependent behavior" "that could be
> called a bug", and you knew exactly what I meant, why bother posting
> "There is no "DontEnum bug"?
First of all, I did not know what you were referring to, as the term
"DontEnum bug" for this behavior was unknown to be. Secondly, in
retrospective, there is the distinct possibility that it is wrongfully
called a bug by people who just don't know any better (mind you that MDC is
a *wiki*). Implementation-dependent behavior is allowed by ECMAScript for
its conforming implementations, through its "Conformance" section.
>>> and if required can use and override its parent constructor.
>> Non sequitur.
>
> I'm glad you agree they are more efficient,
I don't, quite the opposite. ("Non sequitur" is Latin for "that doesn't
follow" or "that's a non-conclusive statement".)
> which isn't always about speed.
I have not commented on the efficiency of your approach *there* at all.
> If you have any valid reasons for your other comments It would
> be good to hear them?
<http://www.catb.org/~esr/faqs/smart-questions.html>
>>> It uses one closure per class definition
>> There are still no classes.
> Obviously there are no classes (yet), but you understand what I mean.
That's not the point. The point is that you didn't/don't know what you are
talking about.
>>> which I don't think is a lot.
>> It uses a lot more that you fail to see.
>>
>>> JScript 5.5 has been around for years so I'm not sure why that is
>>> relevant?
>> Windows 2000 will cease to be supported by Microsoft on 2010-04-21 or later
>> (depending on whether there will be a next service pack). There are
>> applications using MSHTML 5.5 besides Web browsers.
>
> When did I mention what I intended to support?
You didn't, and therefore the drawbacks were pointed out to you.
> And the major javascript libraries used by thousands don't seem to share your
> concerns.
So a million flies can't be wrong? The "major javascript libraries" are
mostly junk as well, as we have discussed ad nauseam (that's Latin for
"until sick and tired about doing it") before. Responsible developers avoid
them like the plague; script-kiddies naturally don't.
>>> And it doesn't require "Function.prototype.apply()",
>> Yes, it does. Function.prototype.apply() cannot be emulated.
>
> No it doesn't,
Good that you agree.
> simply pass in the arguments as you would with any
> constructor and use Parent.init.call(this,arg1,ag2,ag3) or use
> whatever method you want to call another function with the correct
> scope.
Which rips your entire approach apart which one target was, mind you,
to ease programming. Well done ...
>>> I've tried to keep the mechanics and syntax as pure and as natural as
>>> possible e.g.
>> But you didn't. The pure and natural syntax of prototype-based inheritance
>> in these prototype-based object-oriented programming languages is very
>> well-documented, and it differs very much from your approach.
>
> Yes it is well documented. The syntax is different but the mechanics
> are the same.
Well, they are not.
> I'm not using this.parent(), this.$super(), etc.
You appear to be referring to different documentation than I.
> I'm still using the native way of calling parent methods.
That's beside the point.
> I'm not looping through properties and copying them from one object
> to another, I'm adding them directly to the prototype
Congratulations for making the first step on the learning curve.
> e.g. Constructor.prototype.method How does that differ "very much"?
RTFM.
>>> "p.punch" is the same as "Boxer.prototype.punch" which is the native
>>> way.
>> You don't know what you are talking about.
>
> In what way?
In many ways.
>>> "base.punch.call(this,iPunchCount + 100)" is the same as
>>> "Fighter.prototype.punch.call(this,iPunchCount + 100)"
>> If Function.prototype.call() is supported. (However, this is a method that
>> can be rather efficiently emulated for primitive values.)
>
> Like I have said, you can use ANY way you want. I prefer call() and
> apply().
Apparently you don't read what I write, or you interpret things in it that
simply aren't there.
>>> again this is the native way of calling parent methods,
>>> how else would you call parent methods?
>> There are other ways, discussed at great length before.
>
> Great. Then as I have said you are not tied to any particular way. The
> native call() and apply() work great.
The problem is largely not simply ith your calling Function.prototype.apply().
>>> and therefore less margin for errors,
>> Nonsense. The margin for errors has merely shifted to within the
>> implementation of the approach which cannot be fixed just as easily once a
>> sufficient amount of code has been written based on it. Prototype.js and
>> jQuery tell.
>
> If you write no code you can write no errors. If you write more code
> you can write more errors. Simple. What would need fixed, it is using
> a constructor and prototype, that is basic javascript.
It is a distorted, inefficient, clueless version of "basic javascript",
whatever you think that is.
>>> and less bytes.
>> When you've grown up you'll probably recognize that size is not everything.
>
> Less with the patronising, it's pretty pathetic.
The problem with that is merely that it doesn't make you think.
>>> Constructor names aren't hard coded into class specs
>> There are no classes.
> Obviously there are no classes (yet), but you understand what I mean.
See above.
>>> And by adding this slight abstraction it allows for additional helper
>>> methods such as Implements, which I'm all for.
>> All of that can be done using a much simpler pattern.
>
> I fail to see the complexity in this?
See above.
>>> For all the above benefits, you still have performance near native
>>> function C(){}; C.prototype.method = something...
>> There are ways to create prototype objects that don't involve consecutive
>> assignments to properties of prototype objects.
>
> In what I am trying to achieve (see the other implementations on the
> test page) it is extremely fast.
It is extremely slow as compared to the readily available alterative.
> If you have an alternative implementation where the performance
> if significantly better then I would like to see it?
Not every request is to be ended with a `?'.
> I would also add it to the test cases for
> others, showing your different approach.
Google is your friend. [psf 6.1]
>>> I don't think it's too bad lol
>> ^^^
>> It appears you deserve what you get. (Whatever you take, take less of it.)
>
> Again less with the patronising, it's pretty pathetic.
Why don't you simply don't repeat the offending behavior?
>> Anyway, why did you post here in the first place? To be padded on the back
>> for which great invention that you made? You can be certain that it is
>> mostly inefficient hard-to-maintain junk instead, repeating the mistakes of
>> many others before you. Congratulations.
>> [...]
>
> See the start of this reply. Could you please provide some evidence to
> support your opinion "that it is
> mostly inefficient hard-to-maintain junk instead"?
No. We have been over this.
> I fail to see how this is the case.
Apparently.
> Hopefully I haven't offended you in this reply as it is NOT my
> intention.
Yeah, sure. You are just as presumptuous and unwilling to learn anything as
any script neophyte I've come across over the years could be. It's a waste
of time to try teaching sense into you. Have a nice rest of life.
Score adjusted
PointedEars
atwork8
an anal person.
>"Get a life"
I think we both know who this applies to. Put down the mirror and move
on.
Reiss
RobG
OK, so what you are really saying is that using prototype-based
inheritance is better than other methods? Seems the "mixin" thing
wasn't part of your thesis and has ended up as a red herring. It would
also be good to quote the references you've used and whose work you
are building on - if nothing else, it provides a bit of context.
Are you really saying you want to develop a better
"maker" (Crockford's expression) function?
You may be interested in the following threads - not really sure why
Crockford is given credit for the method, perhaps because his blogs on
it get the most attention:
"Crockford's JavaScript OOP system"
<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fc74c84dfefe26a0/c63eae48f41921cb?lnk=gst&q=+Crockford%27s+JavaScript+OOP+system+#c63eae48f41921cb
>
"Crockford's Prototypal Inheritance Function"
<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f1b02a8715a33f0/2c8abbdd24eefc7a?lnk=gst&q=+Crockford%27s+JavaScript+OOP+system+#2c8abbdd24eefc7a
>
--
Rob
Dr J R Stockton
g2000yqf.googlegroups.com>, Tue, 3 Mar 2009 03:12:03, atwork8
<atw...@hotmail.co.uk> posted:
>@PedanticEars - You got me! I was hoping to get the "most awesomest
>post ever" award, and maybe even "bestest javascript discovery of the
>past decade". Seriously though, I've simply asked a question on a
>newsgroup and I'm not sure why that merits such a harsh response from
>yourself? If my response to you was offensive in any way then please
>accept my apology.
It is considered good manners, and prudent, to read the previous
articles of at least a few days before posting. If you had done that,
you would already known what PE is like. Unfortunately, he has not had
the sort of education which instils good manners, consideration for
others, and suchlike. Alas, although he has been advised to seek
professional advice about this, there is no sign that he has ever
benefited from having any. There is, probably, only one cure.
--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Jonathan Fine
> Hi Kangax,
>
> Thanks for the constructive feedback, it's appreciated. And thanks for
> the enumeration bug confirmation.
And thank you, atwork8, for your diligent work on this subject.
BTW, I'm quite interested in this subject, but might not have time to
participate in the discussion this week.
best regards
Jonathan
kangax
The "mixin" function (as you call it) is a dead simple (shallow) copying
of properties (or references, to be more precise, and only those that
are allowed to be enumerated over) from one object to another. Your
"extend" (a.k.a Crockford's "beget", which was actually, if I'm not
mistaken, mentioned first by Lasse as "inherit", long time ago) does
indeed allow to "augment" an object by injecting another object into its
prototype chain. The time to extend an object with "beget"/"inherit" is
theoretically a constant; time spent on for/in -based extension, on the
other hand, is proportional to the number of enumerable members of an
object.
The common use case for iteration (for/in), that I've seen, are usually
aimed at simulating super-like functionality.
For example, something similar to this function is often used for
augmenting "subclass" methods with the reference to their "super"
counterparts.
function inherit(ctr, superCtr, properties) {
function F(){ };
F.prototype = superCtr.prototype;
ctr.prototype = new F();
for (var prop in properties) {
if (typeof superCtr.prototype[prop] == "function") {
ctr.prototype[prop] = (function(prop) {
return function() {
this.base = superCtr.prototype[prop];
return properties[prop].apply(this, arguments);
}
})(prop);
}
else {
ctr.prototype[prop] = properties[prop];
}
}
};
It is then used like so:
function Person(name) {
this.name = name;
}
Person.prototype.say = function() {
return 'My name is ' + this.name;
}
function Employee(name, dept) {
this.name = name;
this.dept = dept;
}
inherit(Employee, Person, {
say: function() {
return this.base() + ', and I work in ' + this.dept;
}
})
new Employee('Joe', 'IT').say(); // "My name is Joe, and I work in IT"
--
kangax
blechler
I'm with you man. IMO PointedEars has made a post to this group an
invitation for a flame war. That is why I very rarely read what is
posted here anymore, and I don't bother posting. Allow me to take
this opportunity to apologize on behalf of the people of Germany, and
those of German heritage.
The best thing that can happen to this group is for PointedEars to go
to his troll cave and stay there. Until then I have nothing further
to add.
Andrew Poulos
I don't need people to make me feel "good" about my coding. I need
knowledge people to tell me when my code is poorly done and how, if
possible, to improve it. I applaud PointedEars and the posts he makes to
this group.
Andrew Poulos
Richard Cornford
<snip>
> ... (a.k.a Crockford's "beget", which was actually, if I'm not
> mistaken, mentioned first by Lasse as "inherit", long time ago) ...
<snip>
My recollection was that Lasse called it "clone", and a long time ago
turned out to be July 2003:-
<URL: http://groups.google.fr/group/comp.lang.javascript/msg/5d06e72e55d5bf11
>
Richard.
Jorge
>
> I don't need people to make me feel "good" about my coding.
Nor people to make you feel any worse, I guess.
> I need
> knowledge people to tell me when my code is poorly done and how, if
> possible, to improve it.
And of course RTFM is of great help, yeah.
> I applaud PointedEars and the posts he makes to
> this group.
When the victims become emotionally attached to their victimizers...
--
Jorge.
kangax
You're right, of course, and that's the exact post I was referring to.
--
kangax
Dr J R Stockton
qv1-newsreader-01.iinet.net.au>, Thu, 5 Mar 2009 07:54:19, Andrew Poulos
<ap_...@hotmail.com> posted:
>
>I don't need people to make me feel "good" about my coding. I need
>knowledge people to tell me when my code is poorly done and how, if
>possible, to improve it. I applaud PointedEars and the posts he makes
>to this group.
That is not very thoughtful of you; in fact it is not thoughtful at all.
Others can answer with similar technical knowledge and much greater
humanity; but, of course, Thomas Lahn, having apparently no other
interest in life, always leaps in first, often without thinking
sufficiently about the intent and needs of the questioner. Many have
been driven out of the group because they cannot tolerate Thomas Lahn's
obnoxious attitude.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Andrew Poulos
Do you really believe that his posts have made you into a victim?
Andrew Poulos
John G Harris
wrote:
<snip>
>Many have
>been driven out of the group because they cannot tolerate Thomas Lahn's
>obnoxious attitude.
Yes, it's a pity he follows the example set by John Stockton.
John
--
John Harris
Jorge
> Jorge wrote:
>
> > When the victims become emotionally attached to their victimizers...
>
> Do you really believe that his posts have made you into a victim?
You're the one who is justifying him and this:
"Apparently you are too stup^Wsure of yourself to realize that"
"If you would know what you are babbling about"
(...etc.)
btw, did you find a solution to the "Text to wrap around a static
image" ?
--
Jorge.
atwork8
any further response to it as it had turned a bit sour. Thanks to
those who have read though the drivel and posted a reply.
I'll have some more time tomorrow to post back properly.
Reiss
atwork8
> On Mar 3, 7:03 pm, atwork8 <atwo...@hotmail.co.uk> wrote:
> > Infact the above example isn't great as it's using beget. Hopefully
> > though you'll understand what I'm getting at, by injecting a prototype
> > reference you could eliminate the need for a mixin function. I'll post
> > up a better example of this technique later.
>
> OK, so what you are really saying is that using prototype-based
> inheritance is better than other methods?
I'm not saying that at all. Everything has its pros and cons. My
personal preference is using prototype based inheritance in a more
classical way. I like using a constructor function with its prototype,
I just don't like the syntax used to do it. This is why I like to take
it a step further and add a slight abstraction to create a type of
pseudo class structure.
(a bit of background on my rationale behind different methods)
This topic is obviously heavily related to code reuse, and whether you
use a classical approach or a pure prototypal approach you inevitably
end up achieving the same goal. But what often isn't mentioned when
discussing this, is skill reuse. The people on hear are obviously very
knowledgeable in regard to javascript, and this can only come from
experience, which takes time. The same can be said for how you think
about system design, and then how you implement those ideas, be it
class based, or object based. I don't think it is reasonable to expect
people to completely abandon their skills and adopt a different way of
thinking, when that experience can easily be represented through
javascript's expressive nature. I can't see what difference it makes
whether a classical or prototypal approach is used. What really
matters is using ones skills to ensure a sound system design, and then
implementing that design accordingly.
> Are you really saying you want to develop a better
> "maker" (Crockford's expression) function?
Maybe not so much a maker function, as from my understanding this
would return the object itself. More of a convenient way of using a
pseudo class structure, to return a constructor and its prototype, set
accordingly.
> You may be interested in the following threads - not really sure why
> Crockford is given credit for the method, perhaps because his blogs on
> it get the most attention:
>
> "Crockford's JavaScript OOP system"
> <URL:
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fc74c84dfefe26a0/c63eae48f41921cb?lnk=gst&q=+Crockford%27s+JavaScript+OOP+system+#c63eae48f41921cb
> >
>
>
> "Crockford's Prototypal Inheritance Function"
> <URL:
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f1b02a8715a33f0/2c8abbdd24eefc7a?lnk=gst&q=+Crockford%27s+JavaScript+OOP+system+#2c8abbdd24eefc7a
Excellent read, thanks for those. They haven't really convinced me to
change my approach though :o)
Thanks,
Reiss
Dr J R Stockton
8924D9443D28E23ED5CD>, Thu, 5 Mar 2009 21:25:13, John G Harris
<jo...@nospam.demon.co.uk> posted:
Petulance seems inappropriate for one of your years.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
John G Harris
>In comp.lang.javascript message <tRAKMAH5...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Thu, 5 Mar 2009 21:25:13, John G Harris
><jo...@nospam.demon.co.uk> posted:
>>On Thu, 5 Mar 2009 at 13:33:13, in comp.lang.javascript, Dr J R Stockton
>>wrote:
>>
>> <snip>
>>>Many have
>>>been driven out of the group because they cannot tolerate Thomas Lahn's
>>>obnoxious attitude.
>>
>>Yes, it's a pity he follows the example set by John Stockton.
>
>Petulance seems inappropriate for one of your years.
petulance n irritable temper, peevishness
It's certainly irritating the way you behave like the worst kind of
teacher - the kind who uses sarcasm whenever possible, regardless of
circumstances.
Incidentally, in <URL:http://www.merlyn.demon.co.uk/js-other.htm#SN> it
says
"Then every statement will be terminated by a semicolon."
which is *wrong*, and
"When the parser meets a semicolon (except in for(;;), strings, comment,
&?), the current statement must be complete."
which is also *wrong*.
It's time you refreshed your knowledge of statements.
John
--
John Harris
Dr J R Stockton
8924D9443D28E23ED5CD>, Sat, 7 Mar 2009 15:45:24, John G Harris
<jo...@nospam.demon.co.uk> posted:
>On Fri, 6 Mar 2009 at 13:41:22, in comp.lang.javascript, Dr J R
>Stockton wrote:
>>In comp.lang.javascript message <tRAKMAH5...@J.A830F0FF37FB96852AD0
>>8924D9443D28E23ED5CD>, Thu, 5 Mar 2009 21:25:13, John G Harris
>><jo...@nospam.demon.co.uk> posted:
>>>On Thu, 5 Mar 2009 at 13:33:13, in comp.lang.javascript, Dr J R Stockton
>>>wrote:
>>>
>>> <snip>
>>>>Many have
>>>>been driven out of the group because they cannot tolerate Thomas Lahn's
>>>>obnoxious attitude.
>>>
>>>Yes, it's a pity he follows the example set by John Stockton.
>>
>>Petulance seems inappropriate for one of your years.
>
>petulance n irritable temper, peevishness
>
>It's certainly irritating the way you behave like the worst kind of
>teacher - the kind who uses sarcasm whenever possible, regardless of
>circumstances.
No: only where it is deserved. It is, of course, not necessary that you
should be able to perceive why it is deserved.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
John G Harris
wrote:
>In comp.lang.javascript message <R1RKzaCU...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Sat, 7 Mar 2009 15:45:24, John G Harris
><jo...@nospam.demon.co.uk> posted:
>>On Fri, 6 Mar 2009 at 13:41:22, in comp.lang.javascript, Dr J R
>>Stockton wrote:
>>>In comp.lang.javascript message <tRAKMAH5...@J.A830F0FF37FB96852AD0
>>>8924D9443D28E23ED5CD>, Thu, 5 Mar 2009 21:25:13, John G Harris
>>><jo...@nospam.demon.co.uk> posted:
>>>>On Thu, 5 Mar 2009 at 13:33:13, in comp.lang.javascript, Dr J R Stockton
>>>>wrote:
>>>>
>>>> <snip>
>>>>>Many have
>>>>>been driven out of the group because they cannot tolerate Thomas Lahn's
>>>>>obnoxious attitude.
>>>>
>>>>Yes, it's a pity he follows the example set by John Stockton.
>>>
>>>Petulance seems inappropriate for one of your years.
>>
>>petulance n irritable temper, peevishness
>>
>>It's certainly irritating the way you behave like the worst kind of
>>teacher - the kind who uses sarcasm whenever possible, regardless of
>>circumstances.
>
>No: only where it is deserved. It is, of course, not necessary that you
>should be able to perceive why it is deserved.
See, there you go again.
Have you started your revision on statements yet ?
John
--
John Harris