> 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.
I was talking about decimal proxies, not decimal primitives itself.
Nothing prevents implementing === operator for decimal primitives,
because it's happening on interpreter side. For backward-compatibility
both Decimal() and new Decimal() would be proxies, and again there is
not point of implementing === on programmer-side, because Decimal()
would be singleton proxy, and new Decimal() would create "copy" of
singleton proxy, so we get desired behavior: Decimal(1.1) ===
Decimal(1.1), but Decimal(1.1) !== new Decimal().
>> 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!
Again, I was taling about proxies not primitives like decimal itself.
Primitives are "singletons" by default. I meant the _proxy_ for
decimal object should be implemented as singleton (yes, in future JS
we could use literals like 1.1m, but anyways it is not
backward-compatible).
>> 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.
1.1m would be synonym for Decimal('1.1'). 1.1m would return actual
primitive (which is not backward-compatible), and Decimal('1.1') would
return either frozen singleton proxy _or_ in future actual,
undistinguishable actual literal as 1.1m does.
>> 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.
I meant distinguishing objects like Decimal('1.1') and new Decimal('1.1').
>>> 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.
I'm simplifying things, sorry. But anyways, currently value types and
reference-objects behave the same as far as we talk about ===
operator. === does not look up object in any complicated way, just
checks if reference or primitive value are the same. And that should
stay.
I don't say I understood strawman entirely. Just saying that allowing
programmers to create trap for === would be rather not brilliant idea.
Actually, I'm going read strawman once more, right now :-)
adam.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
