An experiment using an object literal based class definition pattern

Brendan Eich brendan at mozilla.com
Fri Aug 5 12:14:34 PDT 2011


On Aug 5, 2011, at 9:32 AM, Allen Wirfs-Brock wrote:
>>> I did something similar in my first go at this, but there is a problem...
>> 
>> Right, the desugaring from class syntax is fragile and error-prone.
> 
> I not so sure I agree.  It isn't obvious that this code pattern is particularly any more fragile, error prone, or less toolable than some of the class syntax alternatives that have been discussed.  Particular, if a programmer sets up an editor template that inserts:
> const classname = subclass <| function ( ) {
>    super.constructor();
>    this.{
> 
>    };
> }.prototype.{
> 
> }.constructor.{
> 
> };

Let's count the hazards and costs:

1. No hoisted binding.

2. Boilerplate overhead of "const D = B <| function" vs. "class D extends B": 1+2+8=11 vs. 7 (ignoring spaces). Arrow function syntax helps but you still end up with <|...-> cussing.

3. As you already mentioned contra Axel, one cannot transpose .prototype. and .constructor. parts. Worse, if you don't have class methods, you have to end with a runt .constructor followed by a ;.

4. Braces required instead of no braces for section labels.


> It isn't clear why this is necessarily any more fragile (or less temptable) than for example:
> 
> class classname extends superclass {
>   constructor() {
>     this.  =  ;
>   }
> 
> prototype:
> 
> class:
> 
> }

Really? Item (3) is a big hazard. Readability is harmed by the cussing and bracing. The class syntax may not be the best sugar, but it is sweeter and (due to the order requirement of .prototype. before .constructor., and the mandatory .constructor at the end if you don't have class methods) safer.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110805/ed5256ec/attachment.html>


More information about the es-discuss mailing list