On 08.09.2011 20:16, Allen Wirfs-Brock wrote:
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.
Maybe it was also mentioned as a reason in that discussion. Though, I
don't see a big practical usage of this (perhaps maybe except of only
convenience in some functional programming cases; e.g. when you need to
pass the property names aka "keys" to some function which will enumerate
them). In real practical examples it's just inefficient to collent the
properties first and the to go over them via `forEach` of arrays. Simple
`for-in` is enough.
I would better implemented then `Object.forEach` or `Object.forAll`
higher-order functions.
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.
Sure.
I believe that Crockford suggested the name
No, maybe Crockford just gave the publicity on meetings, but clearly the
method was borrowed from Prototype.js.
What's the most funny in this story is that Prototype.js borrowed the
method from Ruby (actually, Prototype.js initially was written only for
Ruby on Rails framework). The whole library is inspired by the Ruby and
the idea of monkey-patching -- this is why Prototype.js augments
built-ins: Array.prototype, String.prototype, etc (Rails uses this
technique heavily also).
Unfortunately, authors of Prototype.js couldn't augment
`Object.prototype` because the library was developed in the times of
ES3-only -- that is, they cannot control `enumerable` (DontEnum)
attribute there. However, if the had such an ability it's clear 100%
that the method `keys` would be an _instance_ method, the same as it is
in Ruby.
Ruby:
foo = {:x => 10, :y => 20}
print foo.keys # [:x, :y]
The other thing to note, that JS in contrast with Ruby doesn't have
concept of a "key" (all of them are "properties"). In Ruby these two
entities are separated: keys are accessed by the square bracket
notation, and properties via dot-notation (the same separation by the
way in Python).
So the thing is that the terminology, implementation, etc are borrowed
from Ruby, but it doesn't correlates with JS terminology. OTOH, who
cares about terminology much if the method is useful? That's why it's
borrowed and standardized as it's standardized. Moreover, since we have
a "virtual" concept of an "array index", then we have the same "virtual"
concept of a "key" as "own enumerable property". So everythings fine
here, and regarding initial letter "why not to have a flag to get
inherited properties" -- it's also from Ruby and handled there in the
same way -- for `foo.methods` method (own methods) and
foo.instance_methods(true) -- including inherited.
but it might have been someone else.
Initially -- authors of Prototype.js, borrowing form Ruby. But I don't
know -- maybe it was Crockford on the meetings as you mention. Anyway,
it doesn't matter much.
"keys" was an obvious name choice as we were thinking about operating on
objects that represented collections of key/value pairs.
Yes, this is true.
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
