A few arrow function specification issues

Axel Rauschmayer axel at rauschma.de
Sat Apr 21 17:44:04 PDT 2012


> 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`.
> 
> This makes me sad. Seems like functions are going to be a little less first class than they were before - and for fairly arbitrary reasons (the introduction of tight-bound |this| in one syntax varietal). And not being able to assume call and apply will work on any given function feels like the road to deprecation. 

They still work, you just cannot set `this`, which you can’t, either, if you use bind:
    > function foo() { "use strict"; return this; }
    > foo.bind("hello").call("abc")
    'hello'

>> 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.
> 
> Again - why do we need to get clunky suddenly?

I’d call it more explicit. Why use an OOP construct if, conceptually, it is just another (non-method) function parameter?

>> b) Functional mixins
> 
> Alternative: use object literals to specify those.
> 
> Functional mixins are flexible and intuitive. I've used them to great effect. Yes there are alternatives but again a little piece of the language dies.

Can you give an example?


>> c) Namespacing by call/apply
> 
> Alternative: use modules.
> 
> See above.

I’m already very happy with Node.js modules and AMDs. Can’t imagine myself going back to manual namespacing.

> 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.
> 
> Overall I don't see this getting simpler. Six |this| rules instead of five; static and dynamic |this| binding instead of just dynamic; loss of guarantee re. the nature of function arguments.

Function arguments won’t change, I’d just expect passing `this` to a function to happen less. Thankfully, we’ll have the spread operator to take over most of apply’s duties.

To me, things become simpler, because I’ll automatically use the right tool:

1. Instead of constructors, I have class declarations that set up subtyping correctly.
2. Method definitions will make sure that `super` works and will be less to type. Dynamic this implies method to me.
3. If I use a function expression inside a method, I always want it to have lexical this. I think that is the default that makes most sense, conceptually.

These are three rules, easy to follow: method versus (non-method) function versus object factory.

> 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.
> 
> Thats three types of functions now. Our legacy code is going to be confused.


A definite possibility. However, the only problem I can see is a function expecting to pass `this` to a callback. If the callback has been created via bind(), it is out of luck, already. Are there other problems?

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120422/050031bc/attachment-0001.html>


More information about the es-discuss mailing list