Sep 27 meeting notes

[Oliver Hunt]

On Sep 29, 2011, at 9:41 AM, Allen Wirfs-Brock wrote:

> 
> On Sep 28, 2011, at 7:40 PM, Oliver Hunt wrote:
> 
>> 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
> 
> But note that such read barriers must be part of every property access including simple method invocations because the instance can escape from the constructor before it is initialized.
> 
>> 
>>   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
>          theWiderWorld(this);  //this escapes from constructor before wibble is initialized
> 
>>       this.bar = bar;
>>       this.wibble = wibble;
>>   }
>> }
> 
>   function elsewhere(obj,key) {
>         var z = obj[key];    //needs read barrier, object might be an incomplete Foo instance and key might be 'wibble'
>         ...
> }
> 
> To accommodate this, each property would seem to need an additional [[Uninitialized]] "attribute" (it could be represented as a distinguished value) which would have to be checked as part of every property access. 
> 
> You could avoid this simply my not having such "const" declarations and leaving it to the class author to use Object.defineProperty to set the [[Writable]] attribute of such properties to false.
> 
> Alternatively, you could just not worry that a const property could escape into the wild in a writable state and the value undefined.
> 
> Presumably the job of the constructor is to establish invariants of the constructed instances. Some of those invariants may involve complex relationships among property values and between the new object and other objects. There are many ways that an object can escape from a constructor before these invariants are fully established.  Why is the "const" invariant any more important than other invariants that we aren't attempting to guarantee?

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.

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.

--Oliver

> 
> allen