Sep 27 meeting notes

[Brendan Eich]

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

> I'm not too concerned about the read barrier -- in terms of runtime cost i a) don't believe it would be something that people actually use :D, b) even if they did use it would be sufficiently uncommon to make the perf cost of a read barrier inconsequential and c) if somehow the read barrier did become expensive there are a large number of optimisations that could reasonably trivially get rid of the cost in hot code.

I agree with you, we shouldn't prematurely optimize.


> In terms of actual initialisation you could say that constant fields can only be initialised in the constructor -- eg. any write outside the constructor throws (as writing to a non-writable property throws anyway this shouldn't be too hard) and the constructor would just be blessed with a magic ability to write to the slot if it had not yet been initialised.

I'm lulling about how ES4-like this is -- we had const as write-once, and non-null types so we needed guaranteed init of non-null-type-annotated consts -- the last design for ES4 that I recall did exactly what you want here.

But this diverges from 'const' the binding form, and we aren't going to loosen that. What do you think about the objection to using the same keyword for two different approaches?

/be