Sep 27 meeting notes

[Oliver Hunt]

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

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

--Oliver

> /be