jasnell / proposal-istypes Goto Github PK

TC-39 Proposal for additional is{Type} APIs

JavaScript 100.00%

proposal-istypes's Introduction

James is a member of the @Cloudflare Workers team, a core contributor to @nodejs, and a member of the Node.js Technical Steering Committee.

https://fosstodon.org/@jasnell

proposal-istypes's People

Contributors

Stargazers

Watchers

Forkers

addaleax rwaldron happy-ferret mrsoto vivek-acco

proposal-istypes's Issues

Why not Reflect.is{Type}?

Hi James,

Before going further, I wanted to thank you for bringing these additions to discussion 🙂

Since the addition of Reflect, I was wondering if all the stuff that does some kind of reflection should be added under this one.

I know we already have Array.isArray, but should we continue moving forward on this direction, or with this that you are proposing is a good time to branch to this other alternative?

Clarification for `Symbol.isBuiltinDetectable` false behavior

It looks obj[Symbol.isBuiltinDetectable] === false results in Bultins.typeof(obj) === typeof obj, but I can't find it explicitly mentioned anywhere.

one-arg is: remove, or harden?

The one-arg Builtin.is is a bit weird.

If it's trying to answer the question "is this built-in", then it should probably return false if the Symbol.builtin method is !== the original one.

However, I'm also not sure of the utility of the one-arg form in the first place.

Builtins.[typeof|is] clarifications

What would the following return, assuming Builtins.is(Foo) === true and Foo is some constructor?

Builtins.typeof(Foo)
Builtins.typeof(Foo.prototype)
Builtins.is(Foo.prototype)
Builtins.is(Foo.bar) (i.e. some property of Foo)

Suggest rename typeof to typeOf

Currently the following is both invalid syntax and extremely confusing:

const { typeof } = Builtin; // SyntaxError
typeof ([]); // "Array"

Why not rename to typeOf such that the following is valid and not ambiguous?

const { typeOf } = Builtin;
typeOf([]); // "Array"

How does this handle subclasses?

class List extends Array {}
// List inherited isArray
List.isArray(new List()) === true;

Without any additional language, this will be the case for all of the methods defined in this proposal. I'm just looking for an acknowledgement that this is the intention or not—I presently have no opinion whether or not that's the right thing across the board, that will take time to consider.

Some points

Set.isSharedArrayBuffer?O_o
At this moment, we haven't (u)int64 in JS, by IEEE754 integers are safe in float representation only up to 2^53, for that we have Number.isSafeInteger, so adding Number.isInt64 and Number.isUint64 seems wrong.
Where is String.isStringIterator?
Generator object is not a function, so why isGeneratorObject should be in Function namespace?
Adding isTypedArray and is(Int|Uint)(8|16|32|64)Array methods to [TypedArray] (%TypedArray%?) seems wrong - Uint8Array.isTypedArray(float32array) or Float32Array.isUint8Array(uint8array) confuses.
Intl is not a part of ECMA262, so adding methods to it should be a proposal for ECMA402.

Include example with Symbol.toStringTag

This is another thing that causes problems. Node's util functions used to check the result of toString(), but that is no longer feasible because of Symbol.toStringTag.

See the note and example on this in https://nodejs.org/api/util.html#util_util_iserror_object.

What's the meaning of Object.isObject？

Does the following pollyflil works?

// http://stackoverflow.com/questions/8511281/check-if-a-value-is-an-object-in-javascript
module.exports = (item) => {
  return (typeof item === 'object' && !Array.isArray(item) && item !== null)
}

Option for non-builtins as well

While this flies in the face of the name referring to Builtin, I'd think it would be useful, as well as semantically pleasing to have another method to return the same values as in your proposal but returning {}.toString.call(val).slice(8, -1) with Symbol.toStringTag for constructed user objects.

One could thus benefit from:

switch (Types.typeOf(obj)) {
    case 'null':
        break;
    case 'MyConstructor':
        break;
    // etc.
}

While this may be technically out of scope for your proposal, I'd think it might be considered together if it is deemed worthwhile.

Opinion against certain functions

I feel like checks like:

isSetIterator
isGeneratorFunction
isMapIterator
isGeneratorObject
isStringIterator

shouldn't be included in language. Using any of them feels like a code smell for me - these classes doesn't have any meaningful internals. There is no actual difference between any iterator and StringIterator. And

In case of isGeneratorFunction it's merely syntax-level distinction - there is no difference between generator and function returning object with the same interface.

A repeated typo is causing all of the isIntX definitions to be wrong

I'll only copy isInt8, because they all have the same issue, so no reason to repeat myself:

Number.isInt8(arg)
Returns true if Number.isNumber(arg) is true and arg is an 8-bit signed integer in the range -2^7 <= arg <= -2^7-1.

When implemented as shown:

function isInt8(arg) {
  return (-Math.pow(2, 7)) <= arg <= (-Math.pow(2, 7) - 1);
}

isInt8(255) === false;
isInt8(127) === false;
isInt8(120) === false;
isInt8(1) === false;
isInt8(-1) === false;

This can likely be rolled into the fixes for #11, eg:

Number.isInt8(arg)

If Type(arg) is Number and arg is an integer in the range -2⁷ through 2⁷-1, inclusive, return true.
Return false.

two-arg `is` applies to prototype chain as well?

When called with a single argument, the Builtins.is() function returns true if the given value is either a built-in object or has a built-in object within its prototype chain.

but

The Builtins.is() function must return false if any of the given values are not built-in objects, or are not the same built-in object. (TODO: Need a better definition of "same").

The two-argument case, for consistency with the one-argument case, should probably include the "or has a built-in object within its prototype chain" bit.

Builtin.typeof(function() {}), 'function' or 'Function'? Same for Builtin.typeof({})

I think it makes more sense for it to be "Function", the reason for this is that the definition of typeof for "function" is essentially just any object with a [[Call]] internal property.

This is a bit confusing when AsyncFunction, GeneratorFunction (and eventually AsyncGeneratorFunction) all also have typeof "function", it seems a bit odd to have this more general typeof value to mean just Function instances.

I feel the same applies to object/Object as well for similar reasons.

I'd rather see the method called Builtin.type and have it by default return the constructor name for object types only using the lower case form for primitive types.

Regarding `typeOf` examples

A few different observations or suggestions regarding the typeOf examples:

new WebAssembly.Module() would I guess give the same as the Module exotic object:

import * as util from './util.js';`
Builtin.typeOf(util);

... so maybe the above should be indicated as such (if not differentiated)?
2. I think NaN and arguments are interesting enough to describe their expected values
3. I'd be curious to know whether it would be expected that host environments like browsers would end up making DOM objects return their name (e.g., HTMLSelectElement), and if so, maybe raising an example possibility would even better demonstrate the potential.

Withdrawn?

I'm very unclear on why this was withdrawn.

The perfect solution is "toStringTag, but brand-checking functions instead of strings" - and it's what toStringTag should have been in the first place. No other solution works because try/catch is awkward and slow, and toStringTag can be forged in both directions.

What more is needed to motivate this proposal being brought again in front of the committee?

Should deleting Symbol.builtin fall back to brand checks?

In the same way as deleting Symbol.toStringTag falls back to brand checks, should this?

Using the example from the readme (which currently erroneously says "non-function value", but should say "non-string value"):

Uint8Array[Symbol.builtin];             // 'Uint8Array'

Builtin.typeOf(new Uint8Array(0));      // 'Uint8Array'

Uint8Array[Symbol.builtin] = undefined;

Builtin.typeOf(new Uint8Array(0));      // 'object'

delete Uint8Array[Symbol.builtin];

Builtin.typeOf(new Uint8Array(0));      // 'Uint8Array' or 'object'?

Object.isGeneratorObject

This leads to the obvious question: should Generator be exposed globally? https://tc39.github.io/ecma262/#sec-generator-objects

(I'm not saying it should, I'm just opening this for discussion)

Bikeshed the name?

With the latest refactor of the proposal (which is awesome!) I don't think the name "Builtin" is appropriate, primarily because it's extensible by design.

What might be a more appropriate name?

`[Symbol.builtin]` and `global.Builtins` should be immutable

The functions included in this proposal should be trustworthy no matter what, IMO. That means that no code should be able to change the [Symbol.builtin] property of an existing object.

I'd go as far as to say that other objects should not be able to claim they are built in, but that excludes the possibility of polyfilling.

Concerns around `Proxy.isProxy`

One of the "features" of proxies is that they are not observables, you can't really determine if an object is profixied or not, and I believe this is something we want to preserve. I suspect @erights has more to say about this.

Additionally, I believe this proposal is about identity discontinuity, and determining if an object is a proxy or not does not qualify as so since the object should pass the identity test when compared to its proxified version.

When looking at the motivations:

Why have a separate Proxy.isProxy() function? For the simple reason that Proxy objects do not act like anything else. The use case justifying Proxy.isProxy() is that, when debugging, it can often be necessary to know if the an object of interest is a Proxy or not.

I don't think that justify the feature, specially when browsers (and probably node will do the same) are providing formatters for console to represent them accordingly. E.g.: I can define a new formatter via window.devtoolsFormatters alongside a weakmap to show my own proxies differently in the console.

My recommendation is to spin out the Proxy.isProxy into its own proposal that we can debate on its own.

Reconciling Spider-Monkey

In Spider-Monkey:

(typeof Function.isGenerator === "function") === true; // Strangely, this doesn't appear to work the way I assumed it would. 

function * g() {}

g.isGenerator() === true;

support for built-in functions/methods

@ljharb @bengl: Should built-in functions and methods also be supported by this? For instance,

Builtin.is(parseInt, vm.runInNewContext('parseInt'));

Builtin.is(Object.toString, vm.runInNewContext('Object.toString'));

This can be accomplished by requiring that such built-in functions be given a [[Builtin]] internal slot and a @@builtin own property of their own.

Note that passing the builtin function and method to Builtin.typeof() (e.g. Builtin.typeof(parseInt)) would still just return 'function'.

Don't use XOR operator in the isInt/isUint functions

The character ^ is the bitwise XOR, so wherever it's written as x ^ y, means: x XOR y, not x to the power of y. To remedy, write with exponent in superscript

What about Error family?

Should EvalError.isEvalError(), RangeError.isRangeError(), ReferenceError.isReferenceError(), SyntaxError.isSyntaxError(), TypeError.isTypeError() and URIError.isURIError() be also part of this proposal?

cross-context instanceof checks facilitated by Frozen Realms proposal?

You might be interested in this, if you have not already seen it:

https://github.com/FUDCo/proposal-frozen-realms

This concept of different execution contexts sharing immutable copies of certain globals could be useful for your cross-context check example.

Imagine if iframes in browsers and VM contexts in Node.js were frozen realms such that global.Date was the very same constructor across different contexts? This could make instanceof or similar proposed checks feasible.

Would `is` and `typeof` be configurable properties of `Builtins`?

I think there are scenarios in which there would be reasons to override/replace these functions.

Concerns around `Builtin.is`

At first glance Builtin.is is confusing, it is also very different from Object.is.

When looking at the README:

The Builtin.is() function returns true if both of the given values have a @@Builtin own property function that each returns values that, after coercion to a string, are strictly equal to one another. Otherwise, return false.

It is not clear to me what's the motivation behind this API. It doesn't seem to be related to the identity discontinuity phenomenon that Builtin.typeOf() is trying to solve.

What about a more general name?

After an initial read through, I'm thinking about ways to generalize some of these names, into a single-named static method. I'm not sure what it would be named, but basically I mean something like:

ArrayBuffer.foo(new ArrayBuffer())
Map.foo(new Map()) === true;
Set.foo(new Set()) === true;
Date.foo(new Date()) === true;
RegExp.foo(new RegExp()) === true;

At the moment, that falls down on AsyncFunction and GeneratorFunction (possibly others), but those could be revisited for global object inclusion.

value2 is not property validated in is()

I'm not using this lib just reading the source code. Given this I find that the way type of value2 is evaluated in is function had an error.

Is function evaluate if value2 is and object and then evaluate if value1 is a function again.

Rationale for userland objects being able to masquerade as a built-in?

I understand that this proposal, by design, allow any object to masquerade as any of the built-ins. What is the rationale for that decision and should this rationale be added to the readme?