An experiment using an object literal based class definition pattern

Brendan Eich brendan at mozilla.com
Mon Aug 8 21:24:16 PDT 2011


On Aug 8, 2011, at 3:14 PM, Allen Wirfs-Brock wrote:

> Let me try a more carefully constructed example:
> 
> class First() {
> class:
>   partner = (new Second).getPartner();

Sure, this isn't going to work unless Second is declared first.


> How do you simply explain why the initialization of competitor works but the initialization but partner does not with out explicitly getting into the concept of de-sugaring which arguably is a difficult concept for unsophisticated programmers.  It's seems much easier to to have a simple rule: must be defined before executed. This doesn't really change anything for references nested inside function bodies but by this rule, confusing things like the above example would be invalid.  If you really wanted to do that you would have to manually decompose it.  I'd be fine with that.

One cannot explain classes without desugaring, but you're right that not hoisting makes the explanation simpler. CoffeeScript does not hoist its translations. Still, I thought I heard someone say class declarations hoist their bindings. Maybe I misheard -- Bob and Mark should weigh in.


>> Extension by copying vs. extension by delegation are two varieties of extension. Some call the copying form "composition".
> 
> I still think the difference is likely to create confusion and I see no need to follow Java in this choice of keyword.  "subs"

No, that's an ugly and unusual contraction. In a language with instanceof and function, it is important to match impedance.


> or "subclass"  might be a possibility. Or possibly:
>    class superclass <| subclass () {
>   }

That's so backward from other binding forms, and from class in other languages, that it won't fly. If you turned the triangle around, that would be progress.


>> My argument is simply that class syntactic sugar can be considered on top of <| and .{ -- there is no "exclusive OR" mandate here. Could be "AND also" ;-).
> 
> My main concern is baking time for getting more complex syntactic sugar (which, BTW, often ends up being more than just sugar) right.  The hoisting issues above are an example of the the sort of complexity that need to be worried about.  Simpler  constructors like <| and .{ are easier to get right and probably have lower long term impact if we get some detail wrong.

Yes, but if we do too little the usability is poor and users won't bother.

I'm hopeful Bob will champion some usable syntax with desugared semantics we can all agree on.

/be



More information about the es-discuss mailing list