Object.keys(): Why no inherited properties?

[Mark S. Miller]

On Thu, Sep 8, 2011 at 9:16 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Sep 7, 2011, at 11:27 AM, Dmitry Soshnikov wrote:
> >
> > 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.
>
>
> 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.
>
> 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.
>
> I don't recall Prototype.js ever being mentioned in the discussions. I
>

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.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110908/7dafd7bd/attachment-0001.html>