On Sep 7, 2011, at 11:27 AM, Dmitry Soshnikov wrote: > On 07.09.2011 20:53, Brendan Eich wrote: >> On Sep 7, 2011, at 9:29 AM, Dmitry Soshnikov wrote: >> >>> On 07.09.2011 19:33, Felipe Gasper wrote: >>>> Why does Object.keys() not allow, as an option, iterating through >>>> inherited properties? >>>> >>> Because it's the same version that is from Prototype.js. I guess it was >>> ported "as is" for compatibility with the library. But IMO, yes, native >>> implementation could provide at least an option for this case (if needed). >> If you mean that an ES5-conforming implementation could add an optional >> boolean parameter to Object.keys, to get inherited enumerable properties >> too, then please, no: that is against the NOTE in Clause 15 (quoting from >> ES5.1): >> > > 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 Allen > >> NOTE Implementations that add additional capabilities to the set of built-in >> functions are encouraged to do so by adding new functions rather than adding >> new parameters to existing functions. >> >> I think we should make this a normative restriction in ES6. >> > > Yes, of course, I think it's way it should be. > > Dmitry. > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
