[[Invoke]] and implicit method calls

Jason Orendorff jason.orendorff at gmail.com
Fri Sep 20 13:53:01 PDT 2013

On Fri, Sep 20, 2013 at 1:17 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 2013/9/20 Jason Orendorff <jason.orendorff at gmail.com>
>> I think .hasOwn() should be removed.
> I assume you're making the case to remove all derived traps then, not just
> hasOwn()?

No, my question about the justification for .hasOwn() is serious and
stands by itself.

> The question is where to draw the line.

I agree.

This kind of goes without saying. We could invent lots more of these
to make various idioms faster. There are places in the spec where we
check [[Has]] and if that's true we follow up with a [[Get]]. Well
hey, we could make that a method, [[IfHasGet]]. But we won't, because
that would be silly.

Indeed we seem to be going the opposite direction, thank goodness.
Some operations that were internal methods in ES5 are plain (albeit
symbol-named) methods in ES6: [[HasInstance]], [[DefaultValue]].
[[CanPut]] is gone altogether (it only appears in one place in the ES6
draft, and I think that’ll just be deleted). These are good changes.

But we regressed on [[HasOwn]] and I don't understand why.

(I see [[Invoke]] as a regression too. Till and Allen’s latest
approach isn’t bad, but it still seems insufficiently motivated.)


More information about the es-discuss mailing list