Sep 27 meeting notes

[Brendan Eich]

On Sep 29, 2011, at 6:14 PM, Oliver Hunt wrote:

> On Sep 29, 2011, at 9:59 AM, Brendan Eich wrote:
> 
>> On Sep 29, 2011, at 4:47 PM, Oliver Hunt wrote:
>> 
>>>> There are some on the committee who object to 'var' in particular; others object to using scoped binding forms to define properties in (default mutable) objects. We can go around this block again, though.
>>> 
>>> The exact token isn't overly important, it could be '@' if we wanted to go down the path of perl and ruby and use random symbols in place of words.  I would prefer var, because that makes sense to me -- just like the reuse of function for method decls.  Python has demonstrated that people don't have a problem with the same keyword producing functions vs methods on classes (see def).
>>> 
>>> That said I don't now what you mean by "scoped binding forms" so I can't comment on the latter part of your reply.
>> 
>> let, const, function.
>> 
>> Using these to define properties puns binding declaration as property definition. Maybe that is ok, but some on the committee object in general, not just to the 'var' keyword (which is bad because 'let' is good ;-).
>> 
>> I think we have had trouble assuming things that work for bindings work for properties. For instance, initialization is required for const, but how would your favorite class syntax initialize a const instance property from a constructor parameter? If 'const' goes where you show 'var', the constructor's parameters are not in scope.
>> 
>> We don't want const x; and later x = 42 -- as recently as July's meeting we reaffirmed that const requires an initializer and that is the only write.
> 
> See my email from 5 minutes ago :D

I saw -- your original sketch did not show wiffle being assigned, though :-P.


> I'm not too concerned about const as i don't believe it's something people will use -- i think type guards are something that people would be much more interested in and they don't have the same problem.

Two points:

1. Just because you don't believe people will use something doesn't mean we should settle for sketchy semantics (if they are sketchy). It seems like you're saying "won't be important, don't worry".

2. Do you mean guards don't have the same problem because we can impute a default well-typed value? I hope not, because we can't -- no static types, rather runtime guards which must be evaluated to know what they mean.


> If you don't want to separate declaration from arbitrarily complex initialiser you're essentially saying the field declaration must be scattered through the constructor -- at which point finding fields becomes more difficult (you can't declare the field until you've done all the work needed to compute the value -> by necessity const field declarations have to be scattered through the constructor), and you lose object shape guarantees.

Or at least, the shape guarantees are there but harder to see and reason about at a glance. I totally agree -- public (and private) declarations in the constructor body are losing.


>  In that case IMO you should simply drop the pretence of declarative fields and switch to a python/ruby-esque class model where a class is defined by the methods present rather than the methods + fields.

See dherman's minimal classes proposal, he minimized it slightly further on the whiteboard, kind of after the meeting / with only a few people looking.

I still think minimal classes is smart if we're going to avoid too high an opportunity cost by working on bigger/alternative class designs.

/be