Do we really need the [[HasOwnProperty]] internal method and hasOwn trap
rossberg at google.com
Wed Nov 14 01:34:16 PST 2012
On 14 November 2012 09:30, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 2012/11/13 David Bruant <bruant.d at gmail.com>
>> For the particular case you've written, when going for hasOwnProperty.call
>> or the in operator, the JS engine knows it needs to output a boolean, so it
>> can "rewrite" (or contextually compile) your trap last line as
>> "e===undefined" (since "undefined" is falsy and objects created by object
>> literals are truthy). In that particular case, the allocation isn't
>> necessary provided some simple static analysis.
>> Maybe type inference can be of some help to prevent this allocation in
>> more dynamic/complicated cases too. I would really love to have implementors
>> POV here.
> I'm very skeptical of this.
> If I may summarize, you're arguing that we can get away with spurious
> allocations in handler traps because JS implementations can in theory
> optimize (e.g. partially evaluate trap method bodies). I think that's
> wishful thinking. Not that implementors can't do this, I just think the
> cost/benefit ratio is way too high.
I agree, this is a particularly daring instance of the "sufficiently
smart compiler" argument.
More information about the es-discuss