On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich <[email protected]> wrote:
>
> The most painful use case is the existence of perfectly reasonable ES5
>> code like:
>>
>>
>> function Point(x, y) { this.x = x; this.y = y; }
>>
>> Point.prototype.toString() { return `<${x},${y}>`; };
>>
>
> You mean
>
> Point.prototype.toString = function () { return ...; };
>
> of course -- but you're using template string new syntax, so why not use
> Object.defineProperty here? Just sayin' ;-).
I did indeed mean the assignment in your correction.
>
>
> Because of the override mistake, this reasonable code no longer works
>> after
>>
>> Object.freeze(Object.prototype);
>>
>> This sucks.
>>
>> SES goes out of its way to not break code that follows ES5 best
>> practices. The above Point code does. That's why SES's
>> tamperProof(Object.prototype) replaces the data properties on
>> Object.prototype with accessor properties whose setter uses
>> [[DefineOwnProperty]] to emulate assignment on a this that is not
>> Object.prototype itself.
>>
>
> Yup, Domenic's #2.
>
> With your #3, perhaps we'd have a less painful way to working around the
>> override mistake.
>>
>
> I think #3, if hacked via @@enumerableWhenAssigned or any such thing, will
> just lead to more bugs. It's too implicit, modal.
>
> Here's an alternative: add an assignment operator variant, spell it :=,
> that overrides. Boom, new code can work around the override mistake.
>
> Point.prototype.toString := function () { return ...; };
>
> Yeah, I remember := being mooted as [[DefineOwnProperty]] sugar taking a
> property descriptor, but I'm throwing this out here. It's simpler and does
> not confusingly vary the RHS to be a propdesc where regular assignment
> evaluates an arbitrary RHS assignment-expression.
>
> Old code will need magic frozen-proto-setter hacks anyway. That ship
> sailed with ES5.
My concern is old code like Point co-existing with new framework code, like
SES, that wants to freeze old prototypes, but is ignorant about all the
particular old client abstractions, like Point, that need to work within
that framework. The new framework code currently must use tamperProof
rather than freeze, which is expensive and not a fully transparent fix.
With #3, the new framework code might instead install an @@something on
these frozen prototypes, leaving the properties on that prototype as data
properties that do not suffer from the override mistake. The result could
be efficient and adequately transparent.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
