|
[Mangled ASCII art again, sorry for the
resend. Slight edit below, you'd have to diff to catch it. /be]
Axel Rauschmayer wrote: 1. Absolutely love the multiple dispatch stuff (slide 10). What class hierarchy? primitives have wrappers but those are not what typeof tests. If you believe Object | +-------+-------+----+----+----... | | | | Boolean Number String Function then where are boolean, number, and string? There's no Value (ValueObject) either. Suppose we build a value object class (constructor/prototype) hierarchy: Object | +-------+-------+----+----+--------+ | | | | | Boolean Number String Function Value | +-------+-------+----+----+------+------... | | | | | boolean number string int64 uint64 ... Would we be better off? Not only is there an abstract Value constructor, but what about double? int32? uint32? In general we would need a semi-lattice like the one depicted here: http://asmjs.org/spec/latest/subtypes.png but without the "-ish", fixnum, and extern types, and with the concrete types listed above. We might add more abstract intermediate types. That is bound to always confuse people (already: “wait – I thought a function was an object”, worse with value objects). I don't hear that typeof f == "function" confuses people -- that's JS's callable predicate for native (ordinary) objects. I do hear sometimes that people wish typeof a == "array" worked, mainly because instanceof doesn't work cross-frame. Anyway, typeof 0L were to result in "object" we'd have not only confusion but lack of a useful value-type query operator. TC39 agreed on the use-case, and it upholds the (typeof x == typeof y && x == y) <=> (x === y) invariant. But maybe it’s the best we can do. There is no total class hierarchy describing all values in JS. If you think we should retrofit one, make that case. Being able to fix typeof null is awesome, though. One could complain that mutating a typeof registry (map-pair) is a hack, but hacks sometimes are the best thing in a pinch, and I don't see a better way. 3. Also love that we’ll get 64 bit integers etc. (slide 11) and user-definable value objects. You can do this with proxies and enough work. Operators are special forms already, so have special semantics that I'm generalizing a bit to be only somewhat more special-cased (the *last* special case, a general extension mechanism). Much as I am a fan of dead languages with multimethods, I'd rather leave it at this for ES7. For the plus operator: This is another way of realizing Function.defineOperator. Is it worth the extra boilerplate? The strong reason to prefer it is to have operatorPlus as a function value to pass around and invoke separately on arbitrary values. One could have both APIs, Function.defineOperator layered on the @operators API. Function.defineOperators was Christian's suggestion and I see the appeal: convenience for users as well as VM implementors (I've implemented it under the hood in SpiderMonkey's int64/uint64 patch). /be |
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
