Object.keys(): Why no inherited properties?
Mark S. Miller
erights at google.com
Thu Sep 8 09:42:03 PDT 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss