<br><br><div class="gmail_quote">On Thu, Sep 8, 2011 at 9:16 AM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Sep 7, 2011, at 11:27 AM, Dmitry Soshnikov wrote:<br>><br>
> No, I just explained from where the roots of Object.keys() -- from Prototype.js. It was just ported "as is", though, IMO, when it was porting, it with the same success could accept this additional parameter. And I assumed that it was ported as is only because to support compatibility with the Prototype.js.<br>

<br>
<br>
</div>Nice theory, but not the way it actually went down. We wanted to provide a function for use in application code that was guaranteed to order the own property names of an object in the same implementation specific order used by  for-in. Use in conjunction with the "Array extras" was contemplated. For simple "flat" collections of properties we want to enabling enumerating over them using the array functions instead of for-in but also to ensure that the processing order would be the same regardless of which technique was used.<br>

<br>
It was thought of as a application layer function rather than as a reflection function.  That was why it was given a simple, short name rather than being called something like getOwnEnumerablePropertyNames.  I believe that Crockford suggested the name but it might have been someone else.  "keys" was an obvious name choice as we were thinking about operating on objects that represented collections of key/value pairs.<br>

<br>
I don't recall Prototype.js ever being mentioned in the discussions. I<br></blockquote><div><br></div><div>I do. We wanted something with this functionality for all the reasons you state. Since Prototype already had one, we just adopted it as is, as Dmitry surmised.</div>
<div><br></div><div><br></div></div>-- <br>    Cheers,<br>    --MarkM<br>