On 14 November 2012 09:30, Tom Van Cutsem <[email protected]> wrote: > 2012/11/13 David Bruant <[email protected]> >> >> 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. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
