Sep 27 meeting notes

[Oliver Hunt]

On Sep 27, 2011, at 10:30 PM, Brendan Eich wrote:

> On Sep 27, 2011, at 4:06 PM, Waldemar Horwat wrote:
> 
>> Trying to understand Oliver's objections to the current class proposal.
> 
> Oliver objects, as do others, to "punning" (my word) declarative syntax to define object properties, and mixing static and dynamic influences. He specifically cited the location of public exportable-definitions in the constructor body, instead of in the class body.
> 
> We then discussed how putting public x,y; for a class Point in the class body requires separate assignments in the constructor body. Without type annotations (guards) the public declaration is easy to leave out -- it seems optional or unnecessary. And in the case of const (public const K) there's no way to initialize with a constructor parameter or other per-construction state. Anyway, this was the counter-argument, heard before.
> 
> Oliver, anything to add?

I feel we're trying to hard to design a relatively common language feature without actually deciding what we want the fundamental semantics to be.

The basic branching point for class in most languages is how properties are added in an instance of a class -- methods seem to be used as the universal "this is a class" concept and so dynamically and statically typed languages have both moved to a declarative model for methods.

So the issue is whether or not we want to have declarative fields on our objects or not.  The general impression I have got from the committee is that we favour a declarative syntax for fields, but we don't want to separative the declarative logic from the action of code.  To me the various syntaxes being thrown around yesterday feel like rather than making a hard decision we're trying to compromise, and our approach to compromising is to average the syntaxes of static and dynamic classes.

This produces a language with hard to understand semantics, as we demonstrated by essentially spending an entire day arguing over the basic semantics of properties -- let alone any of the edge cases.

I would be happy if we went for a python-esque class model where methods are entirely declarative and properties are entirely dynamic, or a more locked down class model (a dynamically typed version of the common C++/Java/CLR/etc class system) so the set of fields is known and guaranteed -- I really don't favour one over the other, but the result of that decision directly effects what we should be attempting to do in syntax land.

Given our apparent desire to have a declarative syntax i don't see why something akin to:

class Foo {
    var bar; // default value -> undefined
    var wibble = 5; // initialised fields desugar to statements at the head of the constructor
    const wiffle; // read barrier on uninitialised

    function someMethod(..) {
         this.bar = foo; // could have a short hand for this.property
    }
    
    constructor (bar, wibble) {
        // extra typing due to the removal of horrible punning
        // but "public bar = bar" or whatever that syntax was is longer
        // than this.bar
        this.bar = bar;
        this.wibble = wibble;
    }
}

function's get shoved on to the prototype chain, and fields go on the instance, inheritance follows reasonably sensibly from that.  Remove the declarative field definitions and you have essentially got python's class model, which seems to be well accepted by a wide array of people, otherwise the question becomes one of how much you want to lock down the resultant object shape.

--Oliver

> 
> /be