An experiment using an object literal based class definition pattern

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Aug 8 22:24:46 PDT 2011


On Aug 8, 2011, at 9:24 PM, Brendan Eich wrote:

> 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.

And Second could be dependent upon First in the same way so reordering doesn't necessarily solve the problem.
> 
> 
>> 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,

Actually,  this is one of my concerns about class declarations. As a major declarative form in the language many users will attempt to understand them as an atomic unit. It will be a problem if they cannot be understand them without desugaring them into something else. 

> 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.

I think it was probably just assumed (including by me) without fully working through the implications of that assumption. 
> 
> 
>>> 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.

Wasn't really seriously, just throwing a bone to character counters ;-)

> 
> 
>> or "subclass"  might be a possibility. Or possibly:
really meant "subclasses" but "subclassof" would certainly be following in the footsteps of "instanceof"

>>   class superclass <| subclass () {
>>  }
> 
> That's so backward from other binding forms,
we don't really have a comparable binding form in ES.  The closest comparable are function declarations and they don't really provide any guidance for this problem.

     class boundSymbol : superclass () { }
might work although, it may be confusing different from property definitions.

> and from class in other languages, that it won't fly.

If required to choose I would favor internal consistency over similarity to other languages.  

> If you turned the triangle around, that would be progress.

Yes, but there are really good arguments the <| ordering, for example:
    protoValue <| {
        ...
        ...
     }

rather than
   
     {
        ...
        ...
     } |> protoValue

and similarly for functions and others multiple line literals. 
    class superclass <| subclass () {}
would be more internally consistent with that and with the desugaring if you want to go that route of explanation.
May be:
   class subclass = superclass <| () { }
would be even more consistent with:
   let subclass = superclass <| function() {};
which means exactly the same thing in the simplest cases.

> 
> 
>>> 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.

Yes, but we have no real evidence one way or the other that the usability  of <| and .{ is poor.  Mostly just assertions based upon minimal use.  

Allen


More information about the es-discuss mailing list