Thanks Allen but you mentioned `Object.mixin` twice while this has been
abandoned so I still have hard time thinking about a concrete real-world
scenario where toMethod is needed. Do you have any code example? The one in
the meeting note is very likely nothing nobody would ever write.

> If instead you coded:

here my problem ... toMethod cannot assume I know what people coded instead
... toMethod looks like a foot-gun able to bring many shenanigans.

If I have an explicit `SuperConstructor.prototype.method.call(this, arg)`
inside an inherited class method I know what I am invoking, I know what
happen to that instance in that moment, I can trust the execution of that
code.

This is what TypeScript is doing to, as far as I remember.

The moment `super` becomes dynamically mutable due toMethod call:

  1. TypeScript will fail as it is
  2. I have no idea what the super method expects from my instance neither
what it does being kinda privileged too being promoted as parent
  3. if every transpiler has to create this magic we will end up in a much
slower intermediate code as it is for `this.super(arg)` resolved
dynamically in redefine.js (1) instead of the direct
`super.proto.method.call`

So far I don't see any win, plus I cannot think of any scenario where this
magic is needed/wanted/useful.

Thanks again for your patience

(1) https://github.com/WebReflection/redefine#classes








On Tue, Dec 3, 2013 at 9:15 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Dec 2, 2013, at 7:51 PM, Andrea Giammarchi wrote:
>
> Reading this:
> http://esdiscuss.org/topic/november-19-2013-meeting-notes#content-6
>
> I was wondering if anyone would be so kind to provide a
> concrete/real-world use case for toMethod() since I am having hard time to
> imagine a scenario where a super can be so easily invoked, being (AFAIK)
> multiple inheritance not allowed right now in ES6 specs.
>
>
> toMethod is a low level primitive that can be used to implement things
> like Object.mixin in a manner that works correctly with functions that
> reference super.
>
>
> When exactly would a piece of code invoke a super withou knowing which one
> is it?
>
>
> Anytime you want to before/after/around wrap a call to the the method that
> would otherwise be invoked.
>
> Anytime you want to define a "mixin" on an object with a known interface
> but multiple implementations.
>
>
> Wouldn't this lead to potential infinite loop within the super invocation
> itself if referenced from a subclass that was already using toMethod()
> within the super() itself?
>
>
> There is a potential for a super invocation-based unbounded recursion
> loops, but it doesn't require the use to toMethod to make it occur.
>  consider
>
> class P { }
> class C extends P {
>     foo() {
>         console.log("f");
>         super();
>     }
> }
> P.prototype.foo=C.prototype.foo;
> (new C).foo();   //infinite recursion outputting lines of f's
>
>
> If instead you coded:
>
> P.prototype.foo = C.prototype.foo.toMethod(P.prototype);
>
> you would not get the infinite recursion, instead you would get two f's
> followed by a "method not found" .
>
> Allen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131203/585ac473/attachment.html>

Thanks Allen but you mentioned `Object.mixin` twice while this has been
abandoned so I still have hard time thinking about a concrete real-world
scenario where toMethod is needed. Do you have any code example? The one in
the meeting note is very likely nothing nobody would ever write.

> If instead you coded:

here my problem ... toMethod cannot assume I know what people coded instead
... toMethod looks like a foot-gun able to bring many shenanigans.

If I have an explicit `SuperConstructor.prototype.method.call(this, arg)`
inside an inherited class method I know what I am invoking, I know what
happen to that instance in that moment, I can trust the execution of that
code.

This is what TypeScript is doing to, as far as I remember.

The moment `super` becomes dynamically mutable due toMethod call:

  1. TypeScript will fail as it is
  2. I have no idea what the super method expects from my instance neither
what it does being kinda privileged too being promoted as parent
  3. if every transpiler has to create this magic we will end up in a much
slower intermediate code as it is for `this.super(arg)` resolved
dynamically in [redefine.js][1] instead of the direct
`super.proto.method.call`

So far I don't see any win, plus I cannot think of any scenario where this
magic is needed/wanted/useful.

Thanks again for your patience

1: https://github.com/WebReflection/redefine#classes