On Apr 19, 2011, at 2:20 PM, Adam Stankiewicz wrote:
>> The reason === comes up with value types/proxies is the goal of supporting
>> decimal and other number types, where 1.1m ===
>> something_computing_fresh_1_1m() must be true.
>
> If 1.1m was defined as singleton proxy, then === would work correctly,
> because both 1.1m and give_new_1_1() return the same proxy.
Value types are supposed to be implementable in hardware if available. You are
assuming they are objects with reference semantics. That contradicts their
purpose and why we are discussing them as a new kind of type.
> Creating
> new proxy each time would cause memory overload, especially
> considering decimals.
Not so. IEEE754r fits in 128 bits and that is efficiently passed and returned
by value, compared to heap-boxing with copy on write or eager heap allocation
and copying -- or as you seem to propose, memoization (which is a deal-killer
in performance terms). Yes, literals should be interned or memoized. Not so
every computed intermediate or final result!
> Additionally in JS something like 2 === new
> Number(2) returns false,
Now you are comparing apples to oranges. "new Number(2)" is explicitly creating
an object with reference type semantics. No one is proposing a "new
Decimal('1.1')" that would do differently, but what we do propose is a literal
1.1m that does not heap-allocate a mutable object.
> so in my opinion it is not good idea, to let
> programmer define ===, even for decimal proxies. And if we let
> programmer create fresh 1_1m objects there would be no way to
> distinguish them, just because of trapped ===.
So? Why do you need to distniguish 1.1 from compute_1_dot_1() today with
IEEE754 binary double precision floating point? You don't.
Same goes for decimal.
>> The problem is objects in JS are reference types currently. Value types or
>> proxies would be objects that, by virtue of being shallowly frozen, say,
>> could be compared by reference or property values. This needs care in
>> spec'ing since the shallow vs. deep freezing may not cover value types with
>> deeper structures that nevertheless want to be compared by value. Deep
>> comparison is possible of course, just more work.
> Exactly. === should be used only as reference-comparator (primitive
> types are somehow singletons).
You are assuming your conclusion. Value types are not reference types, please
re-read the strawmen.
> Creating trap for == gives programmer
> choice what type of comparison (even deep) use for his object.
That's fine but orthogonal to the === issue.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
