<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      I haven't been following very closely some of the most recent
      discussions, so I appologize if my comments have been addressed
      already<br>
      <br>
      Le 23/11/2012 18:48, Allen Wirfs-Brock a écrit :<br>
    </div>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">Changes include:<br>
      <div><br>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>•
          Reorganized Chapter 8 into separate language type and
          specification type sub sections<br>
        </div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>•
          Added Symbol property keys to the definition of the Object
          Type. terminology migration from talking about “property
          names” to “property keys”.<br>
        </div>
      </div>
    </blockquote>
    I support this change. It's somewhat minor, but clearly indicates
    that a shift has occured.<br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>•
          MOP changes: Added [[GetInheritance]]/[[SetInheritance]] as
          internal methods for accessing [[Prototype]] internal
          prototype chain.</div>
      </div>
    </blockquote>
    Why not [[GetPrototype]] and [[SetPrototype]]? We have a absurd
    number of excellent resources (including but not limited to Dmitry
    Soshnikov and Axel Rauschmayer's websites/blogs) which use
    extensively the ES5 internal [[Prototype]]. It's also been very hard
    to get people to understand the difference between .prototype and
    [[Prototype]]. I'm afraid a new change would create a lot of
    confusion.<br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div>
        <div>Added [[[IsExtensible]]/[[PreventExtensions]].</div>
      </div>
    </blockquote>
    ES5 had a note mentioning that there was no standard mechanism to
    set [[Extensible]] from false to true; this new way makes the note
    unnecessary by design of having internal methods instead of an
    internal property. OCaps FTW I guess :-)<br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div>
        <div>Replaced [[Get]]/[[Put]] with [[GetP]]/[[SetP]]. At some
          point we may be able to rename these as [[Get]]/[[Set]].</div>
      </div>
    </blockquote>
    +1 for [[Get]]/[[Set]]. That's the accessor terminology, that's what
    JS devs are used to. It makes the spec easier to read for them.<br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div>
        <div>Eliminated [[GetProperty]], [[CanPut]], [[HasProperty]],
          [[DefaultValue]].</div>
      </div>
    </blockquote>
    So good to see this cleanup :-)<br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div>
        <div>Added Keys, [[OwnPropertyKeys]], [[Freeze]], [[Seal]],
          [[IsFrozen]], [[IsSealed]].<br>
        </div>
      </div>
    </blockquote>
    For both the enumerations and the layer on top of
    [[PreventExtension]], I'm uneasy.<br>
    * [[Enumerate]], [[Keys]] and [[OwnPropertyKeys]] are very close
    operations<br>
    * So are [[PreventExtensions]]/[[Freeze]]/[[Seal]] on one side and
    [[IsExtensible]]/[[IsFrozen]]/[[IsSealed]]<br>
    <br>
    I'm afraid that making them distinct operations increases
    footgun-ness. [[HasProperty]] has been removed in favored of
    [[HasOwnProperty]] (which might be removed in favor of only keeping
    [[GetOwnProperty]], though the conclusion of the discussion was the
    keep both IIRC) because the former could be "robustly" composed
    between <br>
    <br>
    For proxies, [[Extensible]]ity-related operations have invariants so
    inconsistencies between [[PreventExtensions]], [[Freeze]], [[Seal]],
    [[IsExtensible]], [[IsFrozen]] and [[IsSealed]] are impossible.<br>
    However, one can legitimately wonder what will happen if a new
    built-in operation using [[PreventExtensions]] is introduced in a
    later version of ECMAScript. Let's say experience with
    unique/private symbols reveals that the current Object.freeze
    behavior (whatever it is in regard to symbols) is inappropriate and
    that adding a new Object.freezeWithDifferentSymbolHandling is
    introduced. The current pattern suggests that adding new
    [[FreezeWithDifferentSymbolHandling]]/[[IsFrozenWithDifferentSymbolHandling]]
    internals will be the way to go.<br>
    I'm not sure it's a good pattern.<br>
    <br>
    <br>
    The issue seems worse in footgunness scale for enumeration
    operations because different operations could yield completely
    unrelated results. And once again, if it is wanted to add a new
    enumeration operation on syntax surface, it seems that a new
    internal operation will be necessary.<br>
    <br>
    Here is an idea to uniformize the enumeration story while removing
    enumeration inconsistency footgun. I'll describe it in proxy trap
    terms. A unique trap (or internal operation)<br>
    keyEnumerate: () -> iterator for {propertyKey, enumerable}<br>
    There is this unique operation which returns an iterator not for
    property keys, but for an object containing a property key and a
    boolean signifying the enumerable boolean.<br>
    Using this, each userland operation would use this iterator, drain
    it out (unless the iteration is being aborted like by throwing in a
    for-in loop) and filter out based on the exact userland operation so
    that:<br>
    * All would filter out if propertyKey is ever a private symbol<br>
    * Object.getOwnPropertyNames would keep all other property keys
    regardless of the enumerable value<br>
    * Object.keys would filter out properties which are described as
    non-enumerable<br>
    * for-in would filter out non-enumerable and retrieve the different
    keyEnumerate from the prototype chain objects.<br>
    With this unique internal operation, an object is able to
    communicate its intent regarding what's enumerated and each
    enumeration userland operation only keeps what it's interested in.<br>
    <br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div><span class="Apple-tab-span" style="white-space:pre"></span>
        <div><span class="Apple-tab-span" style="white-space:pre"> </span>•
          instanceof operator no longer uses an internal
          method. Instead, extensible via a @@hasInstance symbol-keyed
          regular method.<br>
        </div>
      </div>
    </blockquote>
    I don't remember a discussion on this topic, but I think it's an
    interesting change. Is it for browser APIs?<br>
    There might be an associated security worry here if any object can
    have its @@hasInstance changed, but one good thing is that the
    debate of trapping instanceof ends if it's a symbol-keyed method.<br>
    <br>
    <blockquote
      cite="mid:026FCBA3-3C6D-400D-AC3C-7EA7A06E58F8@wirfs-brock.com"
      type="cite">
      <div>
        <div> </div>
        <span class="Apple-tab-span" style="white-space:pre"></span>•
        Defined all of the functions in the @Reflect module
        corresponding to MOP internal operations.<br>
      </div>
    </blockquote>
    IIRC __proto__ has been agreed to be an data property and there was
    no Reflect.setPrototypeOf operation in the harmony Reflect module
    proposal on purpose so that 'delete Object.prototype.__proto__' at
    any point would be enough to be sure that all [[Prototype]]-setting
    capabilities are removed.<br>
    So I think the Reflect.setPrototypeOf  should be removed.<br>
    <br>
    David<br>
  </body>
</html>