On Thu, May 31, 2012 at 3:14 PM, Allen Wirfs-Brock <[email protected]>wrote:
> For example, somebody might want to replace the existing apply, call, and
> bind methods, with versions that throw an error when invoked on a fat arrow
> or bound function. For example:
>
> (function replaceCall() {
> if (Function.prototype.hasOwnProperty("intrinsicCall")) return;
> Object.defineProperty(Function.prototype,"intrinsicCall", {value:
> Function.prototype.call, configurable:true});
> Function.prototype.call = function(...args) {
> if (this.isBound()) throw new TypeError("Using call method with a
> bound function");
> else return this.intrinsicCall(...args);
> };
> })();
>
> This would seem useful for testing to see if any "bound functions" are
> being used in situations that may be trying to explicitly provide a this
> value.
>
Why does this code not fail the criteria you already offered: it is
branching on a non-semantic private implementation decision[1] of the
author of the function, and so violating an abstraction boundary?
[1] Prior to .bind(), the std way to lexically bind "this" is to rename it
to "that"
var that = this;
addCallback(function() { whatever(that); });
With bind in ES5, we now have the option to say instead
addCallback(function() { whatever(this); }.bind(this));
With fat arrow in ES6, we can also say
addCallback(=> { whatever(this); });
Normally, even without reading the source of addCallback, I'd assume these
three bits of code say the same thing[2]. Even if one could write
addCallback so that it acts differently in these three cases, isn't that a
bad idea?
[2] Except that the third callback cannot be used as a constructor, which
thereby more accurately says what we generally take the first two cases to
be trying to say[3].
[3] In the future, I'll try to avoid any more nested footnotes ;).
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
