“Just because something was done on purpose doesn’t mean it was done for the right reasons” — absolutely true, except that you’re missing the point of prototype languages. wikipedia gives a good description of one, but a fundamental idea is that there are no classes.

it seems, then, Ecma International made a conscious decision to base the standard on a prototype framework. no blunder — design decision. there are probably a lot of things in the background that lend prototyping to be better suited for client-side implementation on a variety of platforms. (take a walk to the other extreme, java. how fast do pages load with an applet? what type of beast would that be for anyone to do casual/quick scripting?)

the reason people are throwing in class emulation is really simple, in my view: what popular server-side languages are prototyping languages? fundamentally, none. they all have some class-based OOP. so it makes sense that people will want to continue working in a paradigm they’re comfortable with (or open up the doors for others to dig into javascript without having to fully understand prototyping, closures, etc.).

having said that, ecma-262 (4th edition) looks like it’ll be bending to popular usage, since it will support classes, packages, and namespaces (though I’m confused how namespaces will function if that ability is pretty much there, syntactically at least). but there’s no mention that they’re ditching the prototyping foundation, so all the syntax support for classes will no doubt function similar to how mootools handles it. syntactic sugar, basically.

the current actionscript is just a different beast for the reasons i just said in the latter paragraph, namely, using ecma-262 4th edition as its core. so it should be expected to be dramatically different than firefox’s javascript. but it’d be interesting to see a direct real-life comparison between the two and what’s functionally different from 3rd and 4th edition when you strip out the type-checking?

(i also think javascript is going to lose appeal when people have to adhere to strongly typed declarations for a language that never had it. it’s annoying for me, anyway. doesn’t make sense, given the context it’s used in.)

And one last point: if it’s not a blunder, why do so many libraries emulate classes? Just because something was done on purpose doesn’t mean it was done for the right reasons.

think if prototyping could really work in a more traditional OO language? (i guess ruby can rename and eval functions to attach to a class at runtime, but i don’t have enough experience to know if changes to a class reflect to any current instances.)

but yeah, no blunder at all. it’s pretty amazing, actually, that you should even be able to emulate typical class functionality.

JR.Widget.TextField = function(h){
JR.Widget.TextField.superclass.constructor.call(this);
this.mixinittextfieldlabel();
this.mergeconf({
cls: ‘jr-textfield’,
textrange: null, // msie
size: 20
},h);
if (this.gut.place){
this.set_place(this.gut.place);
}
};

JR.mix(JR.Widget.TextField, JR.Widget.Common,
JR.Widget.CommonValidation, CommonTextFieldDataValue,
CommonTextFieldLabel, {

set_place: function(s, conf){
[snip]
}
[snip]

}

It’s single-inheritance with mixin support as well. It has scaled to tens of classes. Way cool and even uses namespace (JR) which is non-intrusive.

The Prototype/Mootools “mixin” approach, though, is very handy but even then, i mostly use it for class options and not for any kind of inheritance.