Proposal: `Object.isEmpty(value)`

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: `Object.isEmpty(value)`

Isiah Meadows-2
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
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Object.isEmpty(value)`

Jordan Harband
`Reflect.ownKeys(x || {}).length === 0`?

On Wed, Feb 13, 2019 at 10:31 PM Isiah Meadows <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Object.isEmpty(value)`

Herby Vojčík
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     www.isiahmeadows.com <http://www.isiahmeadows.com>
>     _______________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Object.isEmpty(value)`

Andrea Giammarchi-2
In reply to this post by Isiah Meadows-2
> 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 <[hidden email]> 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
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Object.isEmpty(value)`

Isiah Meadows-2
I meant `true` for those - I had my conditions flipped. My bad.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Thu, Feb 14, 2019 at 8:55 AM Andrea Giammarchi
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> www.isiahmeadows.com
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Object.isEmpty(value)`

Isiah Meadows-2
In reply to this post by Herby Vojčík
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 [hidden email]
On Thu, Feb 14, 2019 at 5:43 AM Herby Vojčík <[hidden email]> 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 <[hidden email]
> > <mailto:[hidden email]>> 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
> >     [hidden email] <mailto:[hidden email]>
> >     www.isiahmeadows.com <http://www.isiahmeadows.com>
> >     _______________________________________________
> >     es-discuss mailing list
> >     [hidden email] <mailto:[hidden email]>
> >     https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss