On Jan 19, 2013, at 6:36 PM, Mark S. Miller wrote: > On Sat, Jan 19, 2013 at 5:15 PM, Allen Wirfs-Brock > <al...@wirfs-brock.com> wrote: >> >> On Jan 19, 2013, at 11:39 AM, Brendan Eich wrote: >> >>> Something was nagging me from the 2011-era debate over private symbols vs. >>> weak maps, and that's the ability of a weak map to implement soft fields on >>> frozen objects. Symbols (private or not) can't do that. >>> >>> Not sure this matters in the current proxy-focused thread, but I thought I >>> would point it out explicitly. >> >> It seems like at the root of this question revolves around what you mean by >> a "frozen object". >> >> In ES5 there is no such concept. There really is only the >> Object.freeze/Object.isFrozen functions. These are defined operationally in >> terms of specific constructs that exist in ES5. There really is no guidance >> in those definitions as to how they should be extended when when new >> constructs are added to the language. >> >> Also, the effect obtained by applying Object.freeze to an object isn't a >> fundamental characteristic of an object. The exact same effect can be >> achieve by a combination of other calls and Object.isFreeze will still >> report true. >> >> Who's to say that a symbol keyed object can't be added to an object after >> Object.freeze has been applied to it. > > Me. We've been over this. With the semantics you suggest, sharing an > immutable object and an immutable Symbol opens a communications > channel. That is why the private symbol freeze exemption exempted > private-symbol-named properties from the non-writability and > non-configurability of freeze, but only for properties that were > already there. Private symbols must not be exempt from > non-extensibility, or you get an unpluggable channel.
Just to be clear, I'm not arguing for any specific semantics. I'm just saying we can't compare alternative solutions to a problem until we have defined all the requirements. Brendan, in his initial reply to my comment, suggested some possible requirements that ES5 Object.freeze or Object.preventExtensions probably don't meet even if we ignore the existence of symbols. > > WeakMaps don't have this problem because you can only add a key to a > mutable weakmap. We can account for the mutablity in terms of > explicitly mutable state. An immutable weakmap, easily achieved by a > trivial wrapping of a weakmap, allows lookup but no further additions, > thereby not opening up a communications channel. And weakmaps don't > need magic exemptions, partial or otherwise. There is no "magic" involved with private symbols, it is just a small matter of specifying how they interact with existing reflection operations. In contrast, if you want relationships formed using Weakmap to appear as if they were object properties then you are asking for an illusion that takes real magic. I'll partially repeat myself from my reply to Brendan. Just because you have two mechanisms that can solve the same program doesn't mean that they are equivalent or that one the mechanism is necessarily redundant. Weakmaps and symbol keyed properties (private or not) are very different mechanism. They each have a variety of uses and differing implementation and performance characteristics. It really is a distraction to focus exclusively on a single use case that might be supported by two different mechanism and use it to argue that only one of the mechanism is needed. > >> Before we can say that we have to define the semantics of symbol keyed >> objects and possibly extend Object.freeze/isFrozen to accommodate those new >> semantics. What's the guidance for doing so? What abstract concept of >> "frozen" do we to apply to the semantics of new language features? > > Let's start with support for ocap reasoning. Or even info flow > reasoning for that matter, which is sufficient for the above issues. OK, those requires are? Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
