Look Ma, no "this" (was: ECMAScript Harmony)

P T Withington ptw at pobox.com
Mon Sep 29 16:23:59 PDT 2008


On 2008-08-25, at 17:26EDT, Kris Zyp wrote:

> This why I would like to ensure that class sugar also used a  
> prototype-based model, so existing class structures are compatible  
> with the new syntax.

[Late to the party..., perhaps the dishes have already been cleared?]

Me too.  If classes are sugar, I would want them to be sugar for  
prototype-based inheritance.  If that is compatible with 'zero class- 
based inheritance', fine.

Whether classes are sugar or not, I would not want them to be used for  
access control.  I'm against instance-private.  I'd much rather see an  
orthogonal module system for controlling access/visibility.

Finally, if classes are sugar, they should not be creating some magic  
'auto-binding method extraction'.  I'd like to see us do away with  
'this' as much as anyone else, but not by sweeping it under the  
covers.  I'd much rather make 'this' explicit and just declare that:

   foo.bar(...)

is sugar for:

   bar(this=foo, ...)

and

   bar(...)

is sugar for

   bar(this=undefined, ...)

---

I hear that this is not a vote, so a bit of rationale:

Like many other AJAX frameworks, we found straight prototype-based  
programming too verbose.  We invented a class syntax (modeled on es4)  
and wrote a translator that 'de-sugars' that into prototype-based  
inheritance.  We've recently brought our translator up to speed to be  
able to translate to as3 (prototype es4, to me), and there was very  
little pain in adapting our class system to map to either prototype-  
or class-based inheritance.  For the work that we want to do, they are  
equivalent.

Since desugaring to closures seems to be mostly about creating private  
instance variables, if you separate out the access control issue from  
your classes, there seems little motivation for that approach.

The 'this' riff is just a personal peeve.  As someone else said on the  
list, you are not going to get everyone to agree what object-oriented  
means. But to me, it definitely does _not_ mean that methods belong to  
instances.  If methods don't belong to instances, what could 'this'  
possibly refer to?




More information about the Es-discuss mailing list