Axel Rauschmayer wrote:
Constants? We don't need no stinking constants! :-P Manifest strings,
a la typeof, are the natural and self-describing upgrade path, if
we're talking typeof (see Subject).
The Reflect namespace object is part of direct proxies, also
populated in SpiderMonkey (not web-facing) by Reflect.parse to get an
AST for a given source string. We could indeed put type-reflecting
method(s) there but I'm loath to add manifest constants. What's wrong
with strings?
Nothing – if it’s only about primitive values. But if you want to have
something that is both Allen’s `class` operator (for objects) and
`typeof` (for primitive values) then constants are the best solution
(that I can think of). I’ve always thought that the distinction
between typeof and instanceof was a bit artificial, it would be nice
if we had something that unified both.
The problem with constants is that users have to manage a closed (by ES
version) manifest constant set. Polyfilling can't necessarily extend the
Reflect constants (or can it? But then what's the advantage over strings?).
Unifying object [[Class]] with typeof -type can be done via strings too.
The problem remains the closed set of constants.
Or do you propose returning functions for objects and strings for
primitives? E.g.:
switch(type(x)) {
case "null": // x is null
...
break;
case "string": // typeof x === "string"
...
break;
case String: // x instanceof String
...
break;
}
No. I would rather an upgrade for typeof, than something that tries to
do two different things under one API.
Object class reflection is frowned upon in Smalltalk for a reason. We
want protocols, structural conventions -- not nominal type tags. Or so I
think!
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
