<!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">
    On 05.09.2011 13:26, Andreas Rossberg wrote:
    <blockquote
cite="mid:CADjR9Nqyqkwi=FMX70tPoQnWGTyhzQYwFMLRYW7-W+v-TavwRA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On 4 September 2011 21:45, Brendan Eich <span
          dir="ltr"><<a moz-do-not-send="true"
            href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div class="im">On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov
            wrote:<br>
            <br>
            > (1) to standardize `toString` (for this particular case
            -- do not remove comments inside);<br>
            ><br>
            > If the (1) is not possible (why by the way?),<br>
            <br>
          </div>
          Because comments are not saved in the compilation process and
          doing so would slow parsing down and take more space. It's not
          obvious this would matter in head-to-head competition with
          other browsers (esp. with minified benchmarks) -- we would
          have to find out.<br>
          <br>
          Switching to source recovery will entrain more space but may
          be tolerable -- except that switching to source recovery is
          work, competing with other demands. There's no free lunch.<br>
        </blockquote>
        <div><br>
        </div>
        <div>
          Plus, it breaks all function-based data abstraction if you can
          reliably reflect on its implementation and then even reify it
          through eval.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    In other words, if to rephrase you, you nevertheless are talking
    about standardization of `toString`, but to make it some like this,
    right? :<br>
    <br>
    Function.prototype.toString = function () {<br>
      throw "Don't break out abstractions, malicious hacker!"<br>
    };<br>
    <br>
    ;)<br>
    <br>
    <blockquote
cite="mid:CADjR9Nqyqkwi=FMX70tPoQnWGTyhzQYwFMLRYW7-W+v-TavwRA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>I am indifferent about the general idea of a doc interface,</div>
      </div>
    </blockquote>
    <br>
    Then I don't think incorrect judging about the concept of an
    "abstraction" is a good topic in this thread (you may open a new
    one). Abstraction is about _abstraction_, it's not about "security".
    Especially in the interpreted dynamically typed language with
    embedded reflection. Abstractions are for programmers. Not for
    "hackers".<br>
    <br>
    Anyway. It's a completely different story.<br>
    <br>
    <blockquote
cite="mid:CADjR9Nqyqkwi=FMX70tPoQnWGTyhzQYwFMLRYW7-W+v-TavwRA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div> but: having to peek at the _implementation_ of something
          (which is what toString does) in order to gather its
          _interface_ description sounds like a fundamental violation of
          basic principles and exactly the wrong way to go about it.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Fundamental principle of an abstraction, once again, is _the
    abstraction_. That is, to provide convenient black box with API
    hiding implementation details. Thus, nobody says it's about security
    and that we can't use things directly if needed. Of course it's a
    bad practice to rely on the internal state. But in case of to string
    it's not even about application level. It's just a meta-reflection.
    Yes, achieved via such way. If it had been implemented at lower
    level (about what I was talking about), then we could get it via
    reflection API, e.g. Function.getDoc(fn).<br>
    <br>
    However, I already mentioned, I already think it makes sense only
    for technologies such as Node.js (i.e. with big standard library on
    which it's needed often to get quickly help), not ECMAScript at its
    core.<br>
    <br>
    Dmitry.<br>
  </body>
</html>