Function.length in fat arrow class method

[leeola]

In the following code, how is it possible to get the length of wtf.bar ?

foo = (a, b, c) ->
bar = (a, b, c) =>

class Wtf
  foo: (a, b, c) ->
  bar: (a, b, c) =>

wtf = new Wtf()
results =
[
  foo.length
  bar.length
  wtf.foo.length
  wtf.bar.length
]
console.log results
# Ouputs: [ 3, 3, 3, 0 ]

As you can see, the combination of the fat arrow and a class instance causes wtf.bar.length to return zero. Is there a workaround for this? Is this "working as intended"? All sorts of various code uses the handy Function.length checks, and the inability to trust Function.length if the user declared the function as a fat-arrow function could cause problems (and already has for me).. Thoughts?

[leeola]

For convenience, here is what the above code compiles to:

var Wtf, bar, foo, results, wtf,
  _this = this,
  __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; };

foo = function(a, b, c) {};

bar = function(a, b, c) {};

Wtf = (function() {

  function Wtf() {
    this.bar = __bind(this.bar, this);

  }

  Wtf.prototype.foo = function(a, b, c) {};

  Wtf.prototype.bar = function(a, b, c) {};

  return Wtf;

})();

wtf = new Wtf();

results = [foo.length, bar.length, wtf.foo.length, wtf.bar.length];

console.log(results);

[michaelficarra]

0 is the length of wtf.bar. If you want the length of the function it's calling internally, access Wtf::bar.length.

[leeola]

I wish this was simply possible...

  __bind = function(fn, me){
      f = function(){ return fn.apply(me, arguments); };
      f.length = fn.length;
      return f
    };

But alas, it seems not to be.

[michaelficarra]

Yep, length is a non-writable property.

[leeola]

0 is the length of wtf.bar. If you want the length of the function it's calling internally, access Wtf::bar.length

Oh i am aware that it is the length of wtf.bar, i feel that it is incorrect to convert the intention of => into wrap your function.

For example, when you use => from outside of a class it basically means "make this refer to the current context, no matter where the function is run from". However, in a class, that is not what it means. => inside a class, and => outside of a class have two distinct differences, and their usage differs.

The point of binding a function is to allow that function to be passed anywhere while preserving the context of this, correct? If so then the usage of => inside of a class works, but it also has side effects. The side effects being that the function you attempt to use, is not your function. Is is a wrapped function, with different contents, and in this example, a different Function.length.

[leeola]

And my point being, is simply.. is this wrong? Should the side affects be addressed? Wtf::bar.length does not work if the function is passed somewhere else, such as a callback in another library. That library is simply going to ignorantly assume that callback.length is the length you want to measure..

[leeola]

@michaelficarra

Why was this issue closed? My point is that CoffeeScript's implementation is not equal to that of Function.prototype.bind, and that it should be resolved.. is this disagreed with? Methods don't get the same equality as Functions?

edit: Is there no way to make a custom implementation of => and __bind that matches Function.prototype.bind?

[michaelficarra]

I'd love to see your suggested compilation. Without abusing eval, there's no way to do what you're asking.

[epidemian]

Without abusing eval, there's no way to do what you're asking.

Unless using Function::bind. But that wouldn't work on IE 6-8, so it wouldn't be acceptable.

@michaelficarra, BTW (and semi-off-topic), are you planing on adding different JS runtime "targets" in the new CS compiler? For example, if someone wanted to target only ECMAScript 5 compliant runtimes, the compiler could rely on things things like Array::indexOf or Function::bind being present at runtime and therefore generate smaller/simpler code.

[leeola]

Are compile options a common thing? Perhaps we could allow for optional targets that would allow CoffeeScript to compile using modernized functions, rather than pigeonholing CoffeeScript into a browser compatibility box? (ie, to actually use Function.prototype.bind) ?

[leeola]

@epidemian hah, i wrote my post before i saw yours (just couldn't submit it at the time). Same train of thought.

[satyr]

Without abusing eval, there's no way to do what you're asking.

Since the parameters are known at compile time,

this.bar = __bind(this.bar, this);

could be:

var _this = this;
this.bar = function(a, b, c) {
  return Wtf.prototype.bar.apply(_this, arguments);
};

No need to use eval there.

[leeola]

Give @satyr a medal!

Is there anything this feature is lacking? For example, the only thing i know of that __bind is lacking is Function.length, so is there any shortcomings for

var _this = this;
this.bar = function(a, b, c) {
  return Wtf.prototype.bar.apply(_this, arguments);
};

?

[michaelficarra]

so is there any shortcomings [...]

• Lots of repeated boilerplate to account for one uncommon scenario.
• It's not like it proxies any other properties of the function -- it just has the same length now.
• Slight change of the behaviour of bound methods. They would now respect prototype changes after the instance they're bound to has been created. See replacing bound methods gives wrong results #1819 and fixes #1819: bound instance methods should reflect prototype changes #1821.

But yeah, @satyr's solution works.