Exposing more isXyz helpers through node_util.cc.

[jdalton]

I noticed that node/src/node_util.cc has

#define VALUE_METHOD_MAP(V)                                                   \
  V(isArrayBuffer, IsArrayBuffer)                                             \
  V(isDataView, IsDataView)                                                   \
  V(isDate, IsDate)                                                           \
  V(isMap, IsMap)                                                             \
  V(isMapIterator, IsMapIterator)                                             \
  V(isPromise, IsPromise)                                                     \
  V(isRegExp, IsRegExp)                                                       \
  V(isSet, IsSet)                                                             \
  V(isSetIterator, IsSetIterator)                                             \
  V(isTypedArray, IsTypedArray)

Which is great!

Is there interest in filling it out with IsWeakMap, IsWeakSet, IsProxy, IsSharedArrayBuffer,
or others?

[cjihrig]

I'm in favor of this, but I know others are not. If you don't mind using a native addon, there is https://github.com/evanlucas/v8is.

[jasnell]

I had attempted to add IsProxy in a recent PR and there was pushback. Like @cjihrig I'd be in favor of this but I'm not sure there is enough consensus.

[jdalton]

Cool. I recently adopted these in Lodash too.

[jasnell]

Ok. Just keep in mind that we tend to treat things on process.binding() as internal and subject to change.

[jdalton]

Yep, yep. Usage is all guarded, checked, & yada yada.

Is there a way to iterate over the V8 Value methods and export the IsXyz ones? That way there's less to manually maintain and as new Value methods are added they're automagically exposed.

[jasnell]

that would be a bit of a hard sell in light of this. There's an ongoing discussion about whether any of the is* methods should continue to be part of the public API

[jdalton]

that would be a bit of a hard sell in light of this. There's an ongoing discussion about whether any of the is* methods should continue to be part of the public API

I think that fits fine with this. I'm asking to expand the node_util bindings not the public util module.

[cjihrig]

I think expanding the bindings layer for things that aren't used in core will be an even harder sell. That said, I still think we should expose the type checking functions that would otherwise require a native addon.

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.

[jdalton]

@jasnell Is there anything moving on utils/built-ins on the TC39 front?

[cjihrig]

It looks like https://github.com/jasnell/proposal-istypes is going to support type masquerading (see jasnell/proposal-istypes#30). For that reason, I'd like to see more of these bindings made available.

[jasnell]

Yes, we're making progress on the proposal... keep in mind that it's still Stage-0 but the goal is get it to Stage-1 or even Stage-2 by around September. Won't be too difficult for us to polyfill either.

[cjihrig]

For me personally, the whole point is to get a data type that cannot be faked anywhere without installing a compiled module.

[jdalton]

I dig these utils for their perf wins. I'd be OK if values with @@builtin, or whatever symbol is settled on, hit a slow path though. I figure if folks want to say a value is duck, then it's their responsibility to ensure it quacks like one or things might get funky.