<!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 bgcolor="#ffffff" text="#000000">
    On 11.10.2010 18:18, Tom Van Cutsem wrote:
    <blockquote
      cite="mid:AANLkTikjxtr=S-CcL=GFGrr_TcOc+Mu9=iTXW5jfOs8Y@mail.gmail.com"
      type="cite"><span class="Apple-style-span" style="font-family:
        arial,sans-serif; font-size: 13px; border-collapse: collapse;">
        <div>In short: the 'get' trap can't distinguish the above two
          cases. This is a pity, and I agree it would be useful for
          'get' to have that information sometimes. There has previously
          been talk on this list of parameterizing 'get' with an
          additional flag to detect get+call vs invoke, but it turned
          out that not all implementations would be able to support it:
          &lt;<a moz-do-not-send="true"
href="https://mail.mozilla.org/pipermail/es-discuss/2010-May/011062.html">https://mail.mozilla.org/pipermail/es-discuss/2010-May/011062.html</a>&gt;</div>
        <div><br>
        </div>
        <div>In retrospect it may not be so bad that this feature isn't
          supported. I can imagine it could lead people to write code
          like:</div>
        <div><br>
        </div>
        <div>get: function(receiver, name, args) {</div>
        <div>
          &nbsp;&nbsp;// suppose that args === undefined implies that the property
          was only queried, not invoked</div>
        <div>&nbsp;&nbsp;if (args === undefined || args.length === 0) {</div>
        <div>
          <div>&nbsp;&nbsp; &nbsp;return 'a';</div>
        </div>
        <div>&nbsp;&nbsp;} else {</div>
        <div>&nbsp;&nbsp; &nbsp;...</div>
        <div>&nbsp;&nbsp;}</div>
        <div>}</div>
        <div><br>
        </div>
        <div>So that <a moz-do-not-send="true" href="http://obj.name">obj.name</a>
          and <a moz-do-not-send="true" href="http://obj.name">obj.name</a>()
          would both return 'a'. This could lead to a lot of confusion,
          since it's hard to quantify what "<a moz-do-not-send="true"
            href="http://obj.name">obj.name</a>" denotes. If it's
          supposed to be a method, then <a moz-do-not-send="true"
            href="http://obj.name">obj.name</a> should return a
          function. If it's supposed to be a getter, then <a
            moz-do-not-send="true" href="http://obj.name">obj.name</a>()
          should call the thing returned by the getter (which, in this
          case, should raise a type error since strings are not
          callable)</div>
      </span></blockquote>
    <br>
    Sorry, this part of your reply was formatted with a small text --
    the same as quote of my letter, so I completely lost it and didn't
    see at all. Just saw it now in es-archive (there is no font size
    formatting). Actually, you answered in this replay on the question I
    was asking in the next letters (including a parametrized&nbsp; `get`).<br>
    <br>
    Regarding this example with undefined args: I think you agree that
    correct check should test `arguments.length` to see whether `args`
    is here. However, as I mentioned, it may be more convenient to
    separate in own place, i.e. to the `noSuchMethod` hook of a proxy
    handler.<br>
    <br>
    Also I think now, that what was named as pros, i.e. ability to have
    funargs and call/apply invariants, in real, not so pros. Because
    users more likely want to catch exactly missing methods (if you
    don't like the word "methods", since there're no methods, there are
    properties, let's say -- missing properties which ended with `call
    expression` at the call-site). And funargs/apply invariants should
    be leaved for _real functions_ (existing or ad-hoc, explicitly
    returned from the `get`). Moreover, as it has been mentioned, such
    returning has broken === invariant anyway (and also broken invariant
    with non-existing properties).<br>
    <br>
    So I still propose to include to proxy handlers either this
    parametrized&nbsp; `get` with the third `args` parameter, or a separated
    noSuchMethod/methodMissing hook, and do not bother about
    funargs/apply scheme (because, by logic this scheme is even not so
    correct; again -- it should be leaved for _real_ functions of the
    `get`). I am sure, JavaScriptCore can manage this case.<br>
    <br>
    What do you think?<br>
    <br>
    Dmitry.<br>
  </body>
</html>