On Sat, Jan 19, 2013 at 5:15 PM, Allen Wirfs-Brock
<[email protected]> 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.
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.
> 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.
>
> Allen
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
