Bruno Jouhier wrote:
From a dev standpoint what we need is a clean API to discriminate
between types. Sometimes we want to discriminate between objects
(mutable) and values (immutable), sometimes between functions and non
functions, sometimes between numbers, strings and others, etc. And we
don't want to have to write an extra test to exclude null from objects.
As we cannot break the existing typeof and its little warts,
While we can't change typeof null without opt-in, there's good reason to
believe we can extend the co-domain of typeof:
* IE had non-standard results.
* Extant code does not therefore not exhaustively enumerate result value
cases.
* Code does depend on the ==/=== invariant which motivates new typeof
results for value objects (along with usability).
could we introduce a new call, something like Object.typeInfo(x), that
would return a little hash like:
{ type: "int64", immutable: true, number: true, ... }
{ type: "string", immutable: true, number: false, ... }
{ type: "array", immutable: false, number, false, ... }
The first field is and should be what typeof returns.
What does "immutable" mean? We already have Object.isFrozen, etc., in ES5.
The "number" field is misleading in light of typeof 3.14 == "number".
The idea it to have boolean flags like immutable/number/... to
categorize types. This way we can discriminate by testing a flag
instead of having to test complex combinations of typeof,
Array.isArray, etc.
Why would any code need to test combinations of those things to deal
with value objects?
Array.isArray is irrelevant to value objects, but if you want typeof to
return "array" for Array instances (how about subclasses of Array? How
about array-likes?) that could be a separate opt-in. But those
parenthetical questions need answers first.
There's no single typeof result that can tell all interesting facts
about any value, especially composite values such as objects. OTOH there
are good reasons to keep typeof working, and to minimize new APIs (as
always) against *use cases*.
What are the use-cases -- let's say code examples from the field, or
synthetic ones -- that you have in mind for your proposed API?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
