Implicit `this` binding

[ljharb]

It seems potentially dangerous that the top-level this (the receiver in which the block param statement begins) could be implicitly passed to whichever function happens to map to the identifier used.

[ljharb]

(submitted too soon)

The readme says "Block params that are lexically nested in block params get a reference to this:" which implies that the top-level this isn't provided; this seems to address my concern, but does that also mean that functions would be able to detect whether they were a top-level usage or not? Is that a problem?

[samuelgoto]

On Sat, Oct 28, 2017 at 10:45 PM, Jordan Harband notifications@github.com wrote:

(submitted too soon)

The readme says "Block params that are lexically nested in block params get a reference to this:" which implies that the top-level this isn't provided; this seems to address my concern, but does that also mean that functions would be able to detect whether they were a top-level usage or not? Is that a problem?

Right, only the inner blocks would get the "this" reference. Note that, in the current formulation, it would look like:

a { b {} }

looks like

a(function() { this.b(function() { }) })

meaning that "a" is responsible for passing the functions that can be nested. For example:

select (foo) { when (bar) { } }

would result into

select(foo, function() { this.when(bar, function() { }); })

In that, by design, "select" is responsible for a passing a context to the the block param where "when" is defined: otherwise, an error is thrown. E.g.

function select (condition, block) { block.call({ // select is responsible for saying that "when" is allowed inside a select to be written in the form of when (cond) { ... } when: function(value, func) { if (condition == value) { func(); } } }); }

does that make sense? does that sound like the right set of trade offs?

—

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/samuelgoto/proposal-block-params/issues/12#issuecomment-340239321, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqV6guLQoDm-A2HEbxDlXgGyyxjTexpks5sxBEIgaJpZM4QKMuR .

-- f u cn rd ths u cn b a gd prgmr !

[ljharb]

Gotcha - so each block-function would be required to explicitly provide the available block-functions for nesting?

[samuelgoto]

Right.

I "think" that's the right balance (e.g. "switch" is opinionated about enabling "case", "match" IS opinionated about enabling "when", etc), but I written enough tests/use cases to know whether that breaks or not ...

But, FWIW, it addresses specifically the original concern you brought up upon early review (so, hopefully it addresses that concern, but, like I said, still early to know if it creates others :)).

On Sat, Oct 28, 2017 at 11:45 PM, Jordan Harband notifications@github.com wrote:

Gotcha - so each block-function would be required to explicitly provide the available block-functions for nesting?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/samuelgoto/proposal-block-params/issues/12#issuecomment-340241345, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqV6l-_DyAqQbKgE0vy-k6HjAu4Ck2Wks5sxB8GgaJpZM4QKMuR .

-- f u cn rd ths u cn b a gd prgmr !

[ljharb]

Sounds good :-) I thought it was worth filing an issue to clarify, but I think this is addressed.