A few arrow function specification issues

Angus Croll anguscroll at gmail.com
Sat Apr 21 16:33:28 PDT 2012


On Sat, Apr 21, 2012 at 3:06 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

> On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer <axel at rauschma.de>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`.
>

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.

> 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?

>
> 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.

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

See above.


>
> 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.


>
> Currently, quite a bit of cleverness is needed for figuring out how to
> handle `this` (bound, unbound, etc.).
>

Yes, but it hasn't held the language back. JS is mushrooming, and the
growth of new and brilliant code idioms over the last decade has been
amazing. Curbing the dynamic nature of JavaScript might be a more
serious risk to innovation than continuing to require a bit of cleverness.

In any case I suspect adding yet another rule of |this| binding will mean
even more cleverness is needed in ES6.


> 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.


>
>         --
> 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/20120421/ccfb6b20/attachment.html>


More information about the es-discuss mailing list