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