Discuss
  • Dynamic this

Dynamic this

# Herby Vojčík (13 years ago)

Hello,

this is more a conceptual question post. But first some proposals that circulated in the list:

  1. Dynamic-this enabled fat arrow functions.

(this, ...) => expr (this, ...) => { body }

  1. ABC (apply/bind/call) shortcuts.

thisobj::identifier(...args) // apply thisobj::identifier // bind thisobj::identifier(arg, arg, ...) // call

Now, I like them both. I like this dynamic this being in the language and things that it allows (ad-hoc methods). Sure it can be used wrong ways, as everything.

The question is: is dynamic this liked (in the sense, is it the feature which we see as valuable and as one we want proudly have in the language) or is there rather the footgun/no-one-uses-it-right movement for diminishing its role to strange relic?

I saw the mixed opinions.

# John J Barton (13 years ago)

On Mon, Apr 9, 2012 at 10:46 AM, Herby Vojčík <herby at mailbox.sk> wrote:

Hello,

this is more a conceptual question post. But first some proposals that circulated in the list:

  1. Dynamic-this enabled fat arrow functions.

(this, ...) => expr (this, ...) => { body }

  1. ABC (apply/bind/call) shortcuts.

thisobj::identifier(...args) // apply thisobj::identifier // bind thisobj::identifier(arg, arg, ...) // call

Now, I like them both. I like this dynamic this being in the language and things that it allows (ad-hoc methods). Sure it can be used wrong ways, as everything.

The question is: is dynamic this liked (in the sense, is it the feature which we see as valuable and as one we want proudly have in the language) or is there rather the footgun/no-one-uses-it-right movement for diminishing its role to strange relic?

Or 3. Add this feature after we have experience with => use models. (I

assume nothing in => prevents its later adoption; existing function() works

in the meantime).

Just like max/min classes, we should avoid any complications that slow lexical 'this'. Once lexical this lands, then add complications.

The most effective way to grow ES is shorter faster feature cycles.

jjb

# Russell Leggett (13 years ago)

I had been working on a proposal for the bind operator which incorporated short functions, but after consensus was reached on short functions I didn't bother posting it. I think it still has some interesting ideas that you might like. I've posted it here gist.github.com/2345080

tl;dr:

Use @ as a way of doing bind:

needsCallback(foo at bar);
//instead of
needsCallback(foo.bar.bind(foo);

//with |this|
needsCallback(this at bar)
needsCallback(@bar)//shorthand matches this.bar, but does the

additional binding

Also can be used as arbitrary replacement for |this|

class Point {

new(x,y){ //not part of class syntax, just sugar for this.x @x = x; @y = y; } }

Used with short funcs on the RHS

@(x) => { return this.x; } // lexical this
@(x) => this.x // ditto for the expression-body form

I think this could still work as a bind operator without the additional short function stuff. I think it does work well with short functions, but it is probably better to have the default of => be lexical this. The

argument could be made that making it orthogonal as I have here would be a better way of stepping into it, but I also wonder if the extra @s all over the place would be too much.

# Angus Croll (13 years ago)

I like dynamic this.

I favor hard-bound lexical |this| for standalone function calls only. Thats where the problems are right now

The (this, ...) syntax seems unnecessarily gnarly - better to just default to using base ref as |this| in a method call - since by now this is expected behavior