var wr_Root = wr.extend(
function() { alert("wr_Root"); }, {
Method0: function() { alert("Method0"); },
Method1: function() { alert("Method1"); },
Method2: function() { alert("Method2"); },
Method3: function() { alert("Method3"); }
});
var wr_Class1 = wr.extend(
function() {
},
wr_Root, {
Method0: function() {
this.Method1();
this.parent(); // alerts "wr_Root" ("Method0" expected, simple to fix)
this.Method2();
},
Method1: function() {
this.parent();
},
Method2: function() {
try {
this.Method3();
}
catch (e) {};
this.parent(); // alerts "Method3" ("Method2" expected)
},
Method3: function() {
throw new Error("hard to fix =(");
}
});
var Obj1 = new wr_Class1();
Obj1.Method0();

I’m just trying to find bugs in my own code, but they emerge only after I study and test similar code writen by someone else =)

As it was not your intention, please accept my apologizes.

I’m very disappointed, I took the time to write you an argumented reply showing how biased and irrevelant your demonstration is. You choosed not to publish it and instead write this comment pretending I didn’t provided any argument.

This is very childish… continue to truncate people post so you can look like you’re right on your own blog.

No, you’re not passing them into functions, but you use them in functions and when you do so, a reader needs to see whether the identifier resolves to some locally-defined variable, or if it is indeed a global constructor. The fact that “Object” is a global constructor is exactly why you shouldn’t use that “word in a dictionary” ;)

JavaScript allows us to do stuff like {a:1,b:2}[arguments[0]]
I wonder if a superficial lecture of the code could be that helpful to make code specifications useless … I generally agree with you and Micheaux but “for 10 lines code” I do not think this is that big deal.

Those were a bit more than 10 lines : ) Besides, being consistent is good. When you look at the code line-by-line, it is much easier to spot self-executing function if it is wrapped in parenthesis. Do those 2 characters really matter to you? Come on, don’t we have minification/caching these days?

Whatever does Prototype library does not matter for this basic analysis about inheritance … I got on purpose a single weird case and I proposed/analyzed it for some common library. Every library has pros and cons, this is just a single stone in the ocean of possibilities each library offers for daily usage/development, unused toLocaleCase or not.

I understand. Not many libraries take care of DontEnum bug fully, and taking care of most of the `Object.prototype.*` properties can be considered an edge case (aside from toString/valueOf). Prototype.js, also does “DontEnum” test in not most efficient matter – i.e. every time a “class” is created. (disclaimer: I’m one of Prototype.js developers)

Honestly your version is probably more reliable (I cannot update my repository right now since the main hoster is maintaining) but is longer and in my opinion more complicated to understand (less linear)

More reliable? Could you clarify?

At the same time, an array of method names (strings) than cannot contain a dot in the middle, is worthless in my opinion, since for compressors and simplicity I still think that “a.b.c”.split(”.”) is both more simple to maintain and bandwidth saver.

Agreed. dot-separated string looks pretty clean and is easy to maintain.

> Parenthesis are not necessary, but …
JavaScript allows us to do stuff like {a:1,b:2}[arguments[0]]
I wonder if a superficial lecture of the code could be that helpful to make code specifications useless … I generally agree with you and Micheaux but “for 10 lines code” I do not think this is that big deal.

Whatever does Prototype library does not matter for this basic analysis about inheritance … I got on purpose a single weird case and I proposed/analyzed it for some common library. Every library has pros and cons, this is just a single stone in the ocean of possibilities each library offers for daily usage/development, unused toLocaleCase or not.

> The reason I modified your implementation was to make it readable

Honestly your version is probably more reliable (I cannot update my repository right now since the main hoster is maintaining) but is longer and in my opinion more complicated to understand (less linear)

At the same time, an array of method names (strings) than cannot contain a dot in the middle, is worthless in my opinion, since for compressors and simplicity I still think that “a.b.c”.split(”.”) is both more simple to maintain and bandwidth saver.

After all our concerns, there is still the style and thanks Lord we are not machines and we like to code in our way as long as we can understand our code (it took half an hour but you understood everything, same is for me if I read your code style compared to mine)

Finally, how much could we complain for a multiple scope library since we should read the full code instead of a single line?
{toString:function(){return”Regards :D”}}

When I see an identifier named `Function`, I think of a global native `Function` constructor (not the local variable). Every time I see `Object` or `Function` in your code, I need to scan to the beginning of the function, to remind myself whether this is a local variable or it is actually a global constructor. But just to make things even “easier” for me, you also like to put “beginning” of the function in the end of the entire code (when passing it, say, to the self-executing function – the one that’s without parenthesis). I end up scanning your snippet back and forth, trying to figure out things that should be obvious, instead of focusing on the actual idea/implementation : )

Parenthesis are not necessary, but they make it easier to understand that a function you’re looking at (which can be quite lengthy) is not being just declared, but is also executed. I think Micheaux wrote about this issue some time ago (so I’m not alone with this argument)

If you want someone to comment on your code, don’t you want to make it easier for that “someone” to be able to first read/understand what that code does?

> Overrides against obtrusive arguments … uhm, if I do not want to override I use the YUI strategy because for sure I cannot change every function definition, mine or not mine, because a library unshift arguments to send the original one. That is why I defined Prototype implementation the most obtrusive ever.

Prototype.js also relies on function decompilation and that’s not a good thing.

> When your version (and my updated one) will be finished, we can compare speed and code size (gzipped/packed as well) ok?

I don’t really have intentions to “work” on my version or compete with yours. The reason I modified your implementation was to make it readable and remove unnecessary object creation during every constructor invocation (when testing for DontEnum bug). Did it not bother you?

Parenthesis around self executed functions are not necessary when the function returns whatever value and as far as I know you are byte maniac as I am, aren’t you?

Overrides against obtrusive arguments … uhm, if I do not want to override I use the YUI strategy because for sure I cannot change every function definition, mine or not mine, because a library unshift arguments to send the original one. That is why I defined Prototype implementation the most obtrusive ever.

typeof function could be removed without problems and thanks for the tip while for your super fast implementation, as long as you use “my 4 step parent call” I strongly doubt your one will be faster (what I mean is that if you call a variable fn instead of Function do not expect better performances, whatever surrounds that function assignment).

When your version (and my updated one) will be finished, we can compare speed and code size (gzipped/packed as well) ok?

I am looking forward for the next challenge (and for comments like your as well)

Best Regards :-)

I’m sorry but why such vicious coding style?

Why would you name local variables as global constructors – Function, Object, etc. Then there are self executing functions without parenthesis around them.

It took me half an hour just to figure out what’s going on in this seemingly simple example. You’re obviously free to write in whichever way you wish, but what I see now makes it really hard to wade through, understand and comment.

I want to mention that Prototype.js, for example, does not overwrite all of the methods of subclass but only those that have `$super` as their first formal parameter. From what I can see, your implementation overwrites all of the methods, as long as same named method is present in a parent “class”. Speaking of methods, `typeof` function, as you probably know, will produce false positives in Safari (when applied to regex) – turning propeties with regex values into functions that try to call those regexes : )

I was also able to make your `extend` implementation work almost twice faster in FF [1], although IE seemed to be a bit slower (and I have no time to figure out why)

[1] http://gist.github.com/67500