This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A data property of which [[Writable]] is false seems like something we could easily expose and specifications such as https://encoding.spec.whatwg.org/ could make use of for data that is essentially static. The main problem here could be people using it for places where a getter would really work better to be able to lazily compute the object. Hopefully review and implementation stages catch such mistakes. The problem with a data property for which [[Writable]] is true seems to be (I have not verified this): * You cannot have type restrictions. * C++ cannot have fast-path for using it since it has to pierce through into JavaScript to inspect the current value each time it needs it (and then apply some kind of coercion). So perhaps for now we should not allow these.
"[[Writable]] is false" on its own is useless if [[Configurable]] is true.
> * You cannot have type restrictions. Correct. > C++ cannot have fast-path for using it That's true for any data property, really. C++ would have to use some sort of out-of-band state. > "[[Writable]] is false" on its own is useless if [[Configurable]] is true. Not any more so than having a configurable accessor with no setter. The main problem here would actually be that afaict creation of an object with data properties would be slower than of one without, since you have to set up the data properties on it (unlike the current Web IDL accessors, which actually live on the prototype, so only have to be set up once, not per object).
> The main problem here would actually be that afaict creation of an object with data properties would be slower than of one without, since you have to set up the data properties on it (unlike the current Web IDL accessors, which actually live on the prototype, so only have to be set up once, not per object). Can you help me understand why? I've always been curious. It seems like (for the cases where there's really per-instance state, at least) you'd need to store the per-instance state somewhere anyway. I.e., why is it different to have an "internal slot" on the object + a getter on the prototype, vs. a data property on the object?
I can best speak to the Gecko+SpiderMonkey and Servo+SpiderMonkey implementation; it might be worth checking with other implementors in terms of what things look like for them. In the Gecko+SpiderMonkey implementation, allocation of a platform (Web IDL) object is a two-stage process. First the appropriate C++ object is allocated. Then a JS reflection for it is created. The per-instance state that's not lazily computed is stored in the C++ object, so doesn't involve any work on the part of SpiderMonkey at all. In Servo+SpiderMonkey there is a single object, but it has a known list of internal slots and tells SpiderMonkey how many internal slots it wants allocated. These internal slots do not involve any work to allocate past allocating a bigger chunk of memory and default-initializing them with the undefined value. On the other hand, defining a value property on an object involves a bunch of work on the part of SpiderMonkey: updating the hidden shape, updating type inference information, ensuring that there is a slot for the property, etc, etc. Some of these things can be optimized away a bit if the exact set of properties is known up front by preallocating the slots at least; SpiderMonkey doesn't expose public APIs for this, but that can be fixed. But the type inference information and shape information would still need to evolve. Basically, the JIT can optimize access to value props a lot more than built-in getters, but that comes at the cost of needing to do more bookkeeping when setting up the props. In practice, that's worth it in the benchmarks... because those touch the props they set up. But I'm worried about people setting up a whole bunch of "just in case" props.
And it's possible that these are just implementation issues that need to be solved. But they're blocking issues for shipping this stuff, nonetheless.