Norbert Lindenberg wrote:
On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
2) BuiltIn.prototype has state that lets BuiltIn methods successfully operate
on the object, at least as long as they don't modify the state.
True for ES5 objects, currently also true for ES Internationalization objects.
This means Intl.Collator.prototype can be used as a Collator with default
properties, which applications might find useful. Discussion so far
inconclusive.
Mark has a conclusion: don't hide mutable state behind accessors in a
prototype. The reason is that Object.freeze can't freeze such state. Is
Intl.Collator.prototype's state hidden that way, or exposed to Object.freeze?
All state in Collator& Co. instances is hidden in internal properties, but we
don't provide any means to modify the state after construction.
So the state is immutable after construction?
3) The state mentioned in 2) is modifiable.
True for some ES5 objects (Array, Date, RegExp),
Don't forget Object :-P.
I'm thinking of state that goes beyond an empty object and makes a BuiltIn
instance function as a BuiltIn instance. Object instances have no such state.
Can Arrays? Remember, 'length' is observable just a data property and
the custom [[DefineOwnProperty]] or [[Put]] hook is not state.
Of course any prototype object is created extensible, so you can add
properties that aren't relevant to its being a BuiltIn instance.
Indeed (see below).
not true for ES Internationalization objects. The discussion seems to
conclude that modifiable prototype objects are a bad idea.
I'm not sure -- I would say the known problem is hidden (to Object.freeze)
mutable state, not data properties such as RegExp.lastIndex. Mark should
confirm.
Mutable state that can't be frozen is particularly dangerous, but there were
also objections to having Map.prototype or Array.prototype as global storage
bins.
That's no more an issue than any unfrozen prototype including Object,
which is what we're discussing (DavaView.prototype is an Object instance).
The issue is the unfreezable mutable hidden state, which makes a side
channel.
4) Object.getPrototypeOf(BuiltIn.prototype) returns BuiltIn.prototype.
False for ES5 objects and ES Internationalization objects. This would lead to
infinite loops when looking up properties that don't exist, and we probably
don't want that.
Yes, this makes no sense, not a goal in any scenario.
5) BuiltIn.prototype instanceof BuiltIn evaluates to true.
False for ES5 objects and ES Internationalization objects. The ES5 spec for
instanceof relies on 4).
Indeed this cannot be true given that o instanceof C always gets o's [[Prototype]] before
matching against C.prototype -- always hops "one up the chain".
If 4) were true, you'd have an infinite chain, so one hop wouldn't be an issue
at all.
But 4 is false :-P. I was going in order, but if you want to make these
independent, then ok!
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
