possible excessive proxy invariants for Object.keys/etc??

Andreas Rossberg rossberg at google.com
Wed Nov 21 03:54:07 PST 2012


On 21 November 2012 01:06, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>> Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>>>> c) to ensure the stability of the result.
>>>>
>>>> You can think of a + b as implementing a type coercion of the trap result
>>>> to "Array of String". This coercion is not too dissimilar from what the
>>>> getOwnPropertyDescriptor has to do (normalization of the returned property
>>>> descriptor by creating a fresh copy).
>>>
>>> Yes, premature type coercion, in my opinion. Also, a classic performance
>>> mistakes made by dynamic language programmers:  unnecessary coercion of
>>> values that are never going to be access or redundant coercion checks of
>>> values that are already of the property type.  Why is it important to do
>>> such checks on values that are are just passing through these traps.  When
>>> and if somebody actually gets arounds to using one of the elements that are
>>> returned as a property key they will be automatically coerced to a valid
>>> value.  Why is it important that it happens any sooner than that.
>>
>> I don't know if you are familiar with the work of Felleisen et al. on
>> higher-order contracts. In that work, they use the notion of "blame" between
>> different components/modules. Basically: if some module A receives some data
>> from a module B, and B provides "wrong" data, then B should be assigned
>> blame. You don't want to end up in a situation where A receives the blame at
>> the point where it passes that "wrong" data into another module C.
>
> Yes, but ES is rampant with this sort of potentially misplaced blame.  We
> can debate whether such proper "blame" assignment is important or not, but I
> do believe this sort of very low level MOP interface is a situation where
> you want to absolutely minimize none essential work.  I'd sooner have it be
> a little bit more difficult to track now Proxy based bugs then to impact the
> performance of every correctly implemented proxy in every correct program.
> BTW this is a general statement about the entire proxy MOP and not just
> about these particularly property key access traps.

I'm strongly in favour of guaranteeing the contract Tom is mentioning.
However, there is an alternative to copying: we could require the
array (or array-like object) returned by the trap to be frozen. (We
could also freeze it ourselves, but that might be more problematic.)

(The fact that ES is already full of mistakes should not be an excuse
for reiterating them for new features.)

/Andreas


More information about the es-discuss mailing list