<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Le 22/03/2011 23:09, Brendan Eich a écrit :
    <blockquote
      cite="mid:A30D50DD-7670-42E4-B3C9-5065F46153B7@mozilla.com"
      type="cite">
      <div>
        <div>On Mar 22, 2011, at 11:04 AM, David Bruant wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">I wouldn't argue if we
            had: Object.defineDataProperty(o, name, enumerable,
            configurable, writable, value) and
            Object.defineAccessorProperty(...). Or one
            Object.defineProperty with ten arguments. But this is not
            the case.<br>
            I think that part of the reason why the commitee has agreed
            on an object rather than another solution is to have the
            liberty of providing different flavors (there are currently
            two with data and accessor, maybe a third will show up
            eventually) and different attributes one day or another.
            (Can someone from TC39 can provide insights on the property
            attribute API design?)<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        This has already been discussed, and indeed written up as a
        rationale document:</div>
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
          href="http://www.mail-archive.com/es4-discuss@mozilla.org/msg02308.html">http://www.mail-archive.com/es4-discuss@mozilla.org/msg02308.html</a></div>
      <div><a moz-do-not-send="true"
href="http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1:es3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.pdf">http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.pdf</a></div>
    </blockquote>
    Thank you, that's a very interesting document and thread. <br>
    After reading, I feel that the potential of adding other attributes
    wasn't part of the decision design. I was wrong. Still, the
    potential is here.<br>
    <br>
    <br>
    <blockquote
      cite="mid:A30D50DD-7670-42E4-B3C9-5065F46153B7@mozilla.com"
      type="cite">
      <div>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff"> Based on this
            rationale, I think that since proxies have the potential
            entirely redefine their internal consistency, it could make
            sense to completely forget about usual semantics of
            attributes. This actually could be an interesting way to
            drive innovation and maybe that relevant property attribute
            semantics patterns made by library authors could eventually
            be added to the spec.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        Maybe, but should we be strict and explicit, or loose and
        implicit, in our interpretation and handling of the
        currently-spec'ed attributes?</div>
    </blockquote>
    In the spec, for regular (non-proxy) objects, the interpretation and
    handling of currently-spec'ed attribute is and should be strict and
    explicit, I agree.<br>
    For proxy-based objects, our ("we" means "spec writers")
    interpretation and handling of currently-spec'ed attribute is
    non-existent, because as soon as we leave the power of a function to
    a proxy author (for 'defineProperty' and 'getOwnPropertyDescriptor'
    traps), we allow them to choose if they want to consider using
    "configurable" or "enumerable" or not. For instance, we have no way
    to enforce consistency between calls to Object.defineProperty
    ("enumerable" attribute value) and Object.keys. I mean, we could
    enforce consistency here, but if we do, then Object.keys isn't a
    trap anymore, or at least its return value wouldn't mean anything.
    Object.keys would just be the function we know.<br>
    In a proxy-based object, properties created as non-configurable
    could be deleted. Once again, you have no way to enforce that the
    property isn't deletable. <br>
    My point is, you may provide any sort of changes to property
    descriptors, but it doesn't impose anything on how the trap code
    will interpret it. It's not because the spec defines the semantics
    of some attributes that proxy authors will follow the spec.<br>
    <br>
    There is also a potential for future backward incompatibility. If I
    define my own attribute for my own proxy-based objects, let's say
    "deletable", that I use to separate the concerns of deletion and
    configuration. If one day, the ECMAScript standard standardizes the
    attribute and provide a different default value, then all the people
    who relied on my default value will see there code broken, since
    from the trap, I won't be able to see the difference between an
    attribute defined or omitted by a user or an attribute added by the
    engine before my trap code is called.<br>
    So, either you take the risk to break a part of the web each time
    you define a new attribute or you don't standardize it. Providing
    full freedom on the attributes will allow both library authors and
    ECMAScript specifiers to not fight each other when a new attribute
    keyword gets defined in the spec.<br>
    <br>
    I was about to say that since property descriptors are objects,
    proxies could be used instead to fool the engine and pretend
    absorbing the property defining ("enumerable", "configurable")
    calls, but denying them within the trap. It turns out, the
    descriptor passed as an argument and the object within the trap call
    aren't the same object (that's consistent with ES5 and I understand
    this decision), so my idea falls apart.<br>
    <br>
    <br>
    <blockquote
      cite="mid:A30D50DD-7670-42E4-B3C9-5065F46153B7@mozilla.com"
      type="cite">
      <div>I think we will do better with strict and explicit, even as
        we allow libraries (such as Mark and Tom's <a
          moz-do-not-send="true" href="http://traitsjs.org/">http://traitsjs.org/</a>
        library) to extend property descriptors.</div>
      <div><br>
      </div>
      <div><br>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">
            <blockquote
              cite="mid:AANLkTin+yET+-LHZG0ezCnwhH4BWW3qXK72Yi_Z5B=me@mail.gmail.com"
              type="cite">
              <div class="gmail_quote">
                <div>Won't redefining their semantics be needlessly
                  confusing?</div>
              </div>
            </blockquote>
            I cannot answer that question. It will depend on people. For
            the comparison, I would ask:<br>
            How confusing would it be if a host objects redefined
            property attribute semantics? I'm going to provide a
            response below.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        In the last 15 years, host objects have been strange enough that
        the phrase "host object" is a malediction in 43 languages ;-).
         Let's not add loose/implicit opportunities for strangeness.</div>
      <div><br>
      </div>
      <div>Sure, let's hope library authors add new and different
        extensions, and may the least-strange or most-beautiful win, and
        indeed feed into future standard editions.</div>
      <div><br>
      </div>
      <div><br>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">About the surprising
            aspect, I am going to take the example of an host object:
            NodeLists. NodeLists (returned by
            document.getElementsByTagName() ) are live objects. It means
            that once you have created it, it stays in sync with the DOM
            tree without the programmer having to refresh the object in
            any way. This behavior cannot be provided by any regular
            object. So programmers could something equivalent to:<br>
            ---<br>
            var divs = document.getElementsByTagName('div');<br>
            for(var i; i< divs.length ; i++){<br>
                document.appendChild( divs[i].cloneNode );<br>
            }<br>
            ---<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        That's right, NodeLists are live and therefore must be
        implemented by Proxies in a self-hosted DOM. Coming soon at</div>
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
          href="https://github.com/andreasgal/dom.js/">https://github.com/andreasgal/dom.js/</a></div>
    </blockquote>
    Awesome! Will be following that closely!<br>
    <br>
    <br>
    <blockquote
      cite="mid:A30D50DD-7670-42E4-B3C9-5065F46153B7@mozilla.com"
      type="cite">
      <div>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff"> If you haven't loaded
            the module on purpose, well, I think that being surprised by
            object behaviors may be the least of your concerns :-)<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        Ok, but that's your opinion. If others disagree, they won't use
        the library. Over time a winnowing process will sort wheat from
        chaff.</div>
      <br>
      <div><br>
      </div>
      <div>But this is *not* an argument for our core Harmony Proxies
        spec embracing strangeness by being loose or having implicit
        conversions, IMHO.</div>
    </blockquote>
    I'm sorry, I don't understand. What "implicit conversions" are you
    talking about?<br>
    Just to make sure we are on the same page, the discussion we were
    having was about turning property descriptor objects passed as
    Object.defineProperty argument into a "classical" property
    descriptor (data or accessor depending on what is already there)
    while inside the defineProperty trap. This is an implicit conversion
    and this is what I am against. So, what are the "implicit
    conversions" you are against?<br>
    <br>
    <br>
    <blockquote
      cite="mid:A30D50DD-7670-42E4-B3C9-5065F46153B7@mozilla.com"
      type="cite">
      <div><br>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff"> I think I do not really
            understand what is inherently wrong with "surprising" the
            programmer who has chosen to run your code. The programmer
            who has chosen your library did it with <br>
          </div>
        </blockquote>
        <div><br>
        </div>
        (Your sentence ended prematurely there.)</div>
    </blockquote>
    ... and I don't remember what I was going for :-s Sorry.<br>
    <br>
    <br>
    <blockquote
      cite="mid:A30D50DD-7670-42E4-B3C9-5065F46153B7@mozilla.com"
      type="cite">
      <div><br>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">My opinion is that the
            Proxy API should encourage rich internal consistencies as
            much as possible. And trying to keep consistency with what
            we know of current regular objects interfers with that
            vision. Once again, that's just my opinion, I don't mean to
            impose it in any way. (I do not have any power to impose it
            anyway :-p ).<br>
          </div>
        </blockquote>
      </div>
      <br>
      <div>I think this is a bad argument. Proxies (and of course host
        objects implemented in C++ or C) can do all sorts of strange
        things. This does not argue either that (a) proxies *should* be
        used to implement strange objects; (b) the semantics of proxies
        should be stranger than necessary by including implicit
        conversions.<br>
      </div>
    </blockquote>
    Once again, I do not understand what "implicit conversions" you are
    talking about.<br>
    <br>
    <br>
    Overall, one of the point I am rising is the definition of what is
    an object. The ES5 definition says "An object is a collection of
    properties and has a single prototype object. (...)" and each
    property is an "association between a name and a value that is a
    part of an object.". <br>
    In my "PropStackObject" experiment
    (<a class="moz-txt-link-freetext" href="http://davidbruant.github.com/PropStackObjects/">http://davidbruant.github.com/PropStackObjects/</a> (view source)), I
    have created a new object paradigm where a property is an
    association between a name and a stack of values (in a nutshell,
    defineProperty and delete allow to respectively stack up and pop up,
    while get and set only manipulate the value on top of the stack).<br>
    When, in the defineProperty trap, I see a "configurable" attribute
    with "false" as value, since I have changed the object paradigm, I
    have to derive from spec semantics. That's where I said earlier that
    for proxy-based objects, the interpretation and handling of
    currently spec-ed attributes is inexistent. As I have a new
    paradigm, I have to decide what "configurable" mean. Is the whole
    stack becoming non configurable or just the last value? No matter
    how strict and explicit the spec is, no one else but me has to make
    the decision. My preference would be to not consider "configurable"
    at all for my "object paradigm".<br>
    <br>
    David<br>
  </body>
</html>