<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    I have some feedback on the strawman in its current form.<br>
    First, a cosmetic one, at 4. is written "...(FF already acts this
    way, so my previous message was wrong in claiming that
    Object.create(null) fails to avoid this platform on all non-<acronym
      title="Internet Explorer">IE</acronym> browsers.)". I think this
    is a left-over from a copy/paste of the initial email.<br>
    <br>
    The strawman often refers to "context" or "frame" (item 5,
    [[ProtoSetter]] step 2) and I'm not sure this notion is defined in
    ECMAScript. Could a definition be added?<br>
    <br>
    "The previous item presents a problem for proxies. With __proto__‘s
    setter being normative optional, should proxies also have a
    normative optional trap for attempts to set their [[Prototype]]? If
    so, then presumably there should also be such an operation in that
    context’s @reflect module. In that case, it no longer clear what to
    do to lock down a context so that the [[Prototype]] of its objects
    can no longer be mutated."<br>
    => A broader question is whether __proto__ is meant to stay.<br>
    __proto__ started as a Mozilla-specific thing, later added by
    JavaScriptCore, V8 and Opera engine.<br>
    Mozilla had the project to remove it [1]. It generated a long thread
    started by John-David Dalton ("Standardizing __proto__"). One
    notable answer by Brendan [2] suggested a plan to eventually get rid
    of __proto__.<br>
    Some recent information [3] tells us that the mobile ecosystem is
    dominated by __proto__-capable browsers. As a consequence, in
    mobile, some authors would take __proto__ for granted. So much that
    Microsoft would be considering to implement it, thus re-questionning
    the intention to eventually get rid of __proto__.<br>
    <br>
    If __proto__ is meant to stay, considering adding a normative
    optional trap and a function in the @reflect module seems necessary.
    If __proto__ is only codified for the purpose of aligning current
    implementations for better security&interoperability with the
    eventual intention to get rid of it according to the plan Brendan
    described, then the trap and @reflect functions do not seem
    necessary.<br>
    I think that the question is: is __proto__ meant to stay?<br>
    <br>
    An alternative to __proto__ as optional normative could be __proto__
    as optional normative in ES5 and disabled for ES6 (but it would
    require an opt-in different from "use strict"; since ES5 strict mode
    and __proto__ currently coexist in some browsers)<br>
    <br>
    <br>
    [[ProtoSetter]] algorithm<br>
    => Current implementations prevent prototype chain cycles, the
    algorithm, as described doesn't seem to prevent this.<br>
    <br>
    David<br>
    <br>
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=642500<br>
    [2]
    https://mail.mozilla.org/pipermail/es-discuss/2011-March/013162.html<br>
    [3]
    https://mail.mozilla.org/pipermail/es-discuss/2011-December/019083.html<br>
  </body>
</html>