Proposal: `Object.isEmpty(value)`
Reflect.ownKeys(x || {}).length === 0
?
`Reflect.ownKeys(x || {}).length === 0`? On Wed, Feb 13, 2019 at 10:31 PM Isiah Meadows <isiahmeadows at gmail.com> wrote: > This would be roughly equivalent to `Object.keys(value).length === 0`, > but with a few exceptions: > > 1. If `value` is either `null` or `undefined`, it gracefully falls > back to `false` instead of throwing an error. > 2. It takes enumerable symbols into account, like `Object.assign`. > > So more accurately, it returns `false` if the value is neither `null` > nor `undefined` and has an own, enumerable property, or `true` > otherwise. > > It's something I sometimes use when dealing with object-based hash > maps (like what you get from JSON, input attributes). I typically fall > back to the (partially incorrect) `for ... in` with a `hasOwnProperty` > check for string keys, but I'd like to see this as a built-in. > > There's also a performance benefit: engines could short-circuit this > for almost everything with almost no type checks. It's also an obvious > candidate to specialize for types. > > - If it's not a reference type (object or function), return `true`. > - If it's not a proxy object, or a proxy object that doesn't define > `getPropertyDescriptor` or `ownKeys`, it's often just a memory load, > even with dictionary objects and arrays. > - If it's a proxy object with `ownKeys` and/or > `getOwnPropertyDescriptor`, this is the slow path, but you can still > short-circuit when `ownKeys` returns an empty array. > > ----- > > Isiah Meadows > contact at isiahmeadows.com > www.isiahmeadows.com > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190213/b0d59af9/attachment.html>
On 14. 2. 2019 7:54, Jordan Harband wrote:
Reflect.ownKeys(x || {}).length === 0
?
This seems to reify key list. That gist of the OP is probably to be able to be able to tell fast enough if it's empty.
Or are JS engines actually doing this fast (like returning "virtual" keys list for which they can tell .length fast and only actually reify the keys themselves lazily)?
On 14. 2. 2019 7:54, Jordan Harband wrote: > `Reflect.ownKeys(x || {}).length === 0`? This seems to reify key list. That gist of the OP is probably to be able to be able to tell fast enough if it's empty. Or are JS engines actually doing this fast (like returning "virtual" keys list for which they can tell .length fast and only actually reify the keys themselves lazily)? Herby > On Wed, Feb 13, 2019 at 10:31 PM Isiah Meadows <isiahmeadows at gmail.com > <mailto:isiahmeadows at gmail.com>> wrote: > > This would be roughly equivalent to `Object.keys(value).length === 0`, > but with a few exceptions: > > 1. If `value` is either `null` or `undefined`, it gracefully falls > back to `false` instead of throwing an error. > 2. It takes enumerable symbols into account, like `Object.assign`. > > So more accurately, it returns `false` if the value is neither `null` > nor `undefined` and has an own, enumerable property, or `true` > otherwise. > > It's something I sometimes use when dealing with object-based hash > maps (like what you get from JSON, input attributes). I typically fall > back to the (partially incorrect) `for ... in` with a `hasOwnProperty` > check for string keys, but I'd like to see this as a built-in. > > There's also a performance benefit: engines could short-circuit this > for almost everything with almost no type checks. It's also an obvious > candidate to specialize for types. > > - If it's not a reference type (object or function), return `true`. > - If it's not a proxy object, or a proxy object that doesn't define > `getPropertyDescriptor` or `ownKeys`, it's often just a memory load, > even with dictionary objects and arrays. > - If it's a proxy object with `ownKeys` and/or > `getOwnPropertyDescriptor`, this is the slow path, but you can still > short-circuit when `ownKeys` returns an empty array. > > ----- > > Isiah Meadows > contact at isiahmeadows.com <mailto:contact at isiahmeadows.com> > www.isiahmeadows.com <http://www.isiahmeadows.com> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
- If
value
is eithernull
orundefined
, it gracefully falls back
to false
instead of throwing an error.
I am having hard time logically thinking of an empty void as false:
Object.isEmpty(void 0) is false ?
I think keys(o || {}).length === 0 is a more explicit, ambiguity free, alternative.
isEmpty(null) === false when typeof null is still object also doesn't feel too right.
> 1. If `value` is either `null` or `undefined`, it gracefully falls back to `false` instead of throwing an error. I am having hard time logically thinking of an empty void as false: Object.isEmpty(void 0) is false ? I think keys(o || {}).length === 0 is a more explicit, ambiguity free, alternative. isEmpty(null) === false when typeof null is still object also doesn't feel too right. On Thu, Feb 14, 2019 at 7:31 AM Isiah Meadows <isiahmeadows at gmail.com> wrote: > This would be roughly equivalent to `Object.keys(value).length === 0`, > but with a few exceptions: > > 1. If `value` is either `null` or `undefined`, it gracefully falls > back to `false` instead of throwing an error. > 2. It takes enumerable symbols into account, like `Object.assign`. > > So more accurately, it returns `false` if the value is neither `null` > nor `undefined` and has an own, enumerable property, or `true` > otherwise. > > It's something I sometimes use when dealing with object-based hash > maps (like what you get from JSON, input attributes). I typically fall > back to the (partially incorrect) `for ... in` with a `hasOwnProperty` > check for string keys, but I'd like to see this as a built-in. > > There's also a performance benefit: engines could short-circuit this > for almost everything with almost no type checks. It's also an obvious > candidate to specialize for types. > > - If it's not a reference type (object or function), return `true`. > - If it's not a proxy object, or a proxy object that doesn't define > `getPropertyDescriptor` or `ownKeys`, it's often just a memory load, > even with dictionary objects and arrays. > - If it's a proxy object with `ownKeys` and/or > `getOwnPropertyDescriptor`, this is the slow path, but you can still > short-circuit when `ownKeys` returns an empty array. > > ----- > > Isiah Meadows > contact at isiahmeadows.com > www.isiahmeadows.com > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190214/e9de2424/attachment.html>
I meant true
for those - I had my conditions flipped. My bad.
Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com
I meant `true` for those - I had my conditions flipped. My bad. ----- Isiah Meadows contact at isiahmeadows.com www.isiahmeadows.com On Thu, Feb 14, 2019 at 8:55 AM Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote: > > > 1. If `value` is either `null` or `undefined`, it gracefully falls back to `false` instead of throwing an error. > > I am having hard time logically thinking of an empty void as false: > > Object.isEmpty(void 0) is false ? > > I think keys(o || {}).length === 0 is a more explicit, ambiguity free, alternative. > > isEmpty(null) === false when typeof null is still object also doesn't feel too right. > > > On Thu, Feb 14, 2019 at 7:31 AM Isiah Meadows <isiahmeadows at gmail.com> wrote: >> >> This would be roughly equivalent to `Object.keys(value).length === 0`, >> but with a few exceptions: >> >> 1. If `value` is either `null` or `undefined`, it gracefully falls >> back to `false` instead of throwing an error. >> 2. It takes enumerable symbols into account, like `Object.assign`. >> >> So more accurately, it returns `false` if the value is neither `null` >> nor `undefined` and has an own, enumerable property, or `true` >> otherwise. >> >> It's something I sometimes use when dealing with object-based hash >> maps (like what you get from JSON, input attributes). I typically fall >> back to the (partially incorrect) `for ... in` with a `hasOwnProperty` >> check for string keys, but I'd like to see this as a built-in. >> >> There's also a performance benefit: engines could short-circuit this >> for almost everything with almost no type checks. It's also an obvious >> candidate to specialize for types. >> >> - If it's not a reference type (object or function), return `true`. >> - If it's not a proxy object, or a proxy object that doesn't define >> `getPropertyDescriptor` or `ownKeys`, it's often just a memory load, >> even with dictionary objects and arrays. >> - If it's a proxy object with `ownKeys` and/or >> `getOwnPropertyDescriptor`, this is the slow path, but you can still >> short-circuit when `ownKeys` returns an empty array. >> >> ----- >> >> Isiah Meadows >> contact at isiahmeadows.com >> www.isiahmeadows.com >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss
They don't optimize this. Also, in an earlier reply, I mentioned I'm
not a fan of that kind of hack, especially considering the obvious
Reflect.ownKeys(x).length === 0
doesn't work when x
is
null
/undefined
, while for ... of
does.
-----Isiah Meadowscontact at isiahmeadows.comwww.isiahmeadows.com
They don't optimize this. Also, in an earlier reply, I mentioned I'm not a fan of that kind of hack, especially considering the obvious `Reflect.ownKeys(x).length === 0` doesn't work when `x` is `null`/`undefined`, while `for ... of` does. -----Isiah Meadowscontact at isiahmeadows.comwww.isiahmeadows.com On Thu, Feb 14, 2019 at 5:43 AM Herby Vojčík <herby at mailbox.sk> wrote: > > On 14. 2. 2019 7:54, Jordan Harband wrote: > > `Reflect.ownKeys(x || {}).length === 0`? > > This seems to reify key list. That gist of the OP is probably to be able > to be able to tell fast enough if it's empty. > > Or are JS engines actually doing this fast (like returning "virtual" > keys list for which they can tell .length fast and only actually reify > the keys themselves lazily)? > > Herby > > > On Wed, Feb 13, 2019 at 10:31 PM Isiah Meadows <isiahmeadows at gmail.com > > <mailto:isiahmeadows at gmail.com>> wrote: > > > > This would be roughly equivalent to `Object.keys(value).length === 0`, > > but with a few exceptions: > > > > 1. If `value` is either `null` or `undefined`, it gracefully falls > > back to `false` instead of throwing an error. > > 2. It takes enumerable symbols into account, like `Object.assign`. > > > > So more accurately, it returns `false` if the value is neither `null` > > nor `undefined` and has an own, enumerable property, or `true` > > otherwise. > > > > It's something I sometimes use when dealing with object-based hash > > maps (like what you get from JSON, input attributes). I typically fall > > back to the (partially incorrect) `for ... in` with a `hasOwnProperty` > > check for string keys, but I'd like to see this as a built-in. > > > > There's also a performance benefit: engines could short-circuit this > > for almost everything with almost no type checks. It's also an obvious > > candidate to specialize for types. > > > > - If it's not a reference type (object or function), return `true`. > > - If it's not a proxy object, or a proxy object that doesn't define > > `getPropertyDescriptor` or `ownKeys`, it's often just a memory load, > > even with dictionary objects and arrays. > > - If it's a proxy object with `ownKeys` and/or > > `getOwnPropertyDescriptor`, this is the slow path, but you can still > > short-circuit when `ownKeys` returns an empty array. > > > > ----- > > > > Isiah Meadows > > contact at isiahmeadows.com <mailto:contact at isiahmeadows.com> > > www.isiahmeadows.com <http://www.isiahmeadows.com> > > _______________________________________________ > > es-discuss mailing list > > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss at mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > >
This would be roughly equivalent to
Object.keys(value).length === 0
, but with a few exceptions:value
is eithernull
orundefined
, it gracefully falls back tofalse
instead of throwing an error.Object.assign
.So more accurately, it returns
false
if the value is neithernull
norundefined
and has an own, enumerable property, ortrue
otherwise.It's something I sometimes use when dealing with object-based hash maps (like what you get from JSON, input attributes). I typically fall back to the (partially incorrect)
for ... in
with ahasOwnProperty
check for string keys, but I'd like to see this as a built-in.There's also a performance benefit: engines could short-circuit this for almost everything with almost no type checks. It's also an obvious candidate to specialize for types.
true
.getPropertyDescriptor
orownKeys
, it's often just a memory load, even with dictionary objects and arrays.ownKeys
and/orgetOwnPropertyDescriptor
, this is the slow path, but you can still short-circuit whenownKeys
returns an empty array.Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com