> On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer <[email protected]> wrote: > Counter-question: Isn’t it clear when you create a function whether it is > going to be a non-method function or a method? > > It's clear to the implementer - Its not clear to a function that gets it as > an argument - unless fn.prototype is checked
I would argue that – in ES.next – whenever a function is passed as an argument, one should always assume that it is a non-method function and completely ignore `this`. > What is the use case for a non-method function with dynamic this? > > a) Invoke callback in my context Alternative: introduce an additional parameter for the context. > b) Functional mixins Alternative: use object literals to specify those. > c) Namespacing by call/apply Alternative: use modules. Additionally, there are generic methods. But those are methods. And they would work better as non-method functions, anyway. IIRC, there is a proposal for making them available as such (e.g. via a module). Lastly, the main raison d’être of generic functions was `arguments`. With `arguments` on its way out, we’ll need them less. If we can make this work, it will make JavaScript a much simpler language, much easier to understand for newcomers. Hence, I’m not trying to be glib, above, I’m arguing in favor of making things simpler. Currently, quite a bit of cleverness is needed for figuring out how to handle `this` (bound, unbound, etc.). If old-school functions are replaced by class declarations (constructors), arrow functions (non-method functions) and method definitions (methods), one will automatically do the right thing. -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
