executeBound on var arg constructors

[megawac]

As mentioned earlier (#2199), exectueBound doesn't support all of Function.prototype.bind cases on constructors which take variable arguments. As the main implementation of bind no longer uses the native implementation, it's important we fix it.

Lodash currently supports these cases.

var D = _.bind(Date, null, 2015, 05)
new D(10);

[jdalton]

Lodash currently supports these cases.

FWIW lodash didn't support this until 3.9.0 (last month). Not sure if that affects the priority but it's something to consider.

[megawac]

Any hints to get this working jdd?

[jdalton]

See createCtorWrapper. Support is a side effect of patching it to work with ES6 class constructors.

[jridgewell]

I have solutions of varying degrees:

• Revert #2199
  • Slow creation
  • Fast invocation
  • Handles any constructor
• Switch on Function#bind
  • Slow (but slightly faster) creation
  • Fast invocation
  • Handles any constructor
• JDD's new
  • Fast creation
  • Fast invocation
  • Handles any native JS constructor
  • Won't handle ES6 class constructors with 7+ parameters

[jdalton]

I'm not a fan of hybrid (obviously I dig the JDD way :P) but it looks like the Switch on Functin#bind is a preferable hybrid as it forks on definition instead of invocation.

[jashkenas]

Switch on bind does look slightly preferable. Creating a new switch/case pyramid of doom would be distasteful, even more so if it puts an upper limit on the number of arguments.

[megawac]

The issue is the fallback for old ie will be inconsistent

[megawac]

The best way to handle this may be to do as jdd decided and drop explicit support for non es5 and defer this stuff to es5-shim

[jdalton]

@jashkenas

Creating a new switch/case pyramid of doom would be distasteful, even more so if it puts an upper limit on the number of arguments.

I'm OK with the upper limit here as it only affects calls to bound build-ins invoked as a constructor or a bound ES6 class constructors (where supported natively). The upper limit of 7 covers the built-in constructor case and should be reasonable for others. If not it can be revisited/added-to to.

The upside to this approach is consistency across environments and other methods, as I use the bound Ctor behavior for partialed and curried methods as well.