Infrequently Noted

Hi Trevor,

"prototype" means something today, and the we're also defining the constructor and instance object structure here, so perhaps "prototype" would fit, but then we loose the isomorphicness with "function". I'm not sure it matters, though...just as long as we get an easy-to-type-and-read solution that means something sensible in ES5 de-sugaring.

As for multiple inheritance: not gonna happen. There are multi-proto languages in the world, but ES isn't one of them and it would present probably the single largest change to the object model since the first version of the language to do it.

What I'm hopeful that we can do is to start taking the pressure off of inheritance with something like Traits which can have multiple composition per class. Here's some example syntax of the early versions of this supported today by Traceur:

http://code.google.com/p/traceur-compiler/wiki/LanguageFeatures#Traits

Regards

thanks for the clarification from your last post. the only concern I have with using the word "class" is that it comes with so much baggage. maybe just use the word "prototype" instead of "class".

one thing I've never understood is why do all proto-classical implementations only allow to extend from one object? as long as there are no conflicting names it's perfectly reasonable to generate a new object from any number of other objects. how would that syntax be implemented? something like:

export class HugeButton extends BigButton,BiggerButton {}

Nice post.. ES6 will surely make JS code look cleaner. In the above sample how does 'export' relate to ES5? does it mean DropDownButton is now global.DropDownButton?

@Jonathan,

Keep beating that drum! Fast typing and slow reading is bass ackwards, for sure.

@Alec,

Uh, don't want to put words in Jonathan's mouth but he did say "full words", not "long names". People apologize for, for example, the module pattern by claiming it's a "common idiom". That's another way of saying beginners can't read it - not a hallmark of great code.

I'm against shortening of syntax to symbols and shorter keywords. I much rather ES.next use full words and here's why:

Novices and learners don't care about how long it takes to write one line of code, they focus on understanding what they are doing and making it work.

Experienced users want to write as much as possible in as little time as possible. This is where text-expanders and IDEs come in. Shortening typing speed at the expense of readability should not fall under the syntax's obligation, rather the user.

Sure some people would complain about having to type public function myFunc(value() { } over and over again, but the smart programmers will encapsulate that to a text-expander as pfunc+tab or whatever works for them.

Hi Jonathan,

Novices and learners take patterns and re-use them. Arguing for long names -- which might help discoverability for infrequently used -- misses the point. Common idioms gain meaning in part through name and in part through use. The more common a system/idiom, the more the balance shifts to "use" and away from "name". In the context of the language and syntax, that's most often the case. It's a mis-use of syntax to design for discoverability -- even when that might absolutely be the right thing to do for a library.