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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
