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. >> 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. Of course any prototype object is created extensible, so you can add properties that aren't relevant to its being a BuiltIn instance. >> 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. >> 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. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
