2015-06-01 20:36 GMT+02:00 Alexander Jones :
>
>
> On Monday, June 1, 2015, Tom Van Cutsem wrote:
>
>>
>> Or since Proxy traps correspond 1-to-1 to the "internal methods" in the
>> spec, the primary goal of the Reflect API was to expose the essential
>> methods that make up Javascript's object mod
Alexander Jones wrote:
Or since Proxy traps correspond 1-to-1 to the "internal methods"
in the spec, the primary goal of the Reflect API was to expose the
essential methods that make up Javascript's object model as
defined by the spec.
I like this definition. Is it written dow
On Monday, June 1, 2015, Tom Van Cutsem wrote:
>
>
> 2015-06-01 8:38 GMT+02:00 Domenic Denicola >:
>
>> From: es-discuss [mailto:es-discuss-boun...@mozilla.org
>> ] On
>> Behalf Of Gray Zhang
>>
>> > I’m just wondering is there any reason that Reflect API is not suitable
>> to provide such funct
2015-06-01 8:38 GMT+02:00 Domenic Denicola :
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Gray Zhang
>
> > I’m just wondering is there any reason that Reflect API is not suitable
> to provide such functionality?
>
> Reflect currently contains only methods which corresp
Domenic Denicola wrote:
However, in the end, what you need to do to get something into the language is
to prove that it's a common enough need that it's worth adding complexity to
the spec and implementations. This thread is very far from doing that. A better
start would be surveying open-sour
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gray Zhang
> I’m just wondering is there any reason that Reflect API is not suitable to
> provide such functionality?
Reflect currently contains only methods which correspond to proxy traps. There
has been talk of extending i
Sorry but still not exact, the use of Object.getOwnPropertyNames through
prototype chain can result in duplicate keys in override cases, so if we
implement this API ourself it could be quite complex (involving a Map to filter
duplicated keys)
I’m just wondering is there any reason that Reflect
Forgive me for golfing it, but
function getAllPropertyNames(o) {
if (!o) return [];
return Object.getOwnPropertyNames(o) +
getAllPropertyNames(Object.getPrototypeOf(o));
}
or as a generator
function* allPropertyNames(o) {
if (!o) return;
yield* Object.getOwnPropertyNames(o);
Not exactly
Reflect.ownKeys does not walk up prototype chain so it does not return
inherited members
Reflect.enumerate seems not return non-enumerable members
What I propose is an API that returns both non-enumerable and inherited members
Best regards
Gray Zhang
在 2015年6月1日 上午1:15:58, Zhan
Would `Reflect.ownKeys` or `Reflect.enumerate` help you here?
On Sun, May 31, 2015 at 4:42 AM, Gray Zhang wrote:
> Since class’s members are non-enumerable by default (which is a good
> choice) we cannot use for .. in to iterate over all members of an
> instance, the same problem could exists in
10 matches
Mail list logo
