On Mar 31, 2011, at 10:32 AM, Kam Kasravi wrote:
How reasonable would it be to treat 'this' in a similar way that the
prototype chain is referenced when resolving identifiers? I realize there
would be ambiguity for like named identifiers but that problem exists now...
In Allen's first
Thank you Allen for the references and analysis. It's interesting that Gilad
argues resolution should be lexical followed by inheritance to avoid
'unanticipated name capture' that may exist within the inheritance chain.
Probably even less of an option given backward compatibility requirements.
On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
JavaScript up to this point seems to have done a pretty good job of
On Mar 30, 2011, at 5:06 AM, Sam Tobin-Hochstadt wrote:
On Tue, Mar 29, 2011 at 7:08 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[snip]
Optionally allowing explicit use of an alternative receiver name is probably
acceptable as long as there is a default name. The OO tradition is
On 2011-03-29, at 17:52, Allen Wirfs-Brock wrote:
On Mar 29, 2011, at 1:12 PM, P T Withington wrote:
If I had a vote, it would be for a way to explicitly name the `-1th`
argument to a function. And I would wish for it to be available in all
function forms, defaulting to using the legacy
On 2011-03-29, at 17:38, Brendan Eich wrote:
[...]
We did not discuss allowing |this| to be bound otherwise, *except*
#foo(this = this| arg1, arg2) {...}
Am I right in understanding the above to be an idiom for trampolining the outer
`this` binding into the closure? (With the hazard that
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as a
function, it uses the lexical binding of |this|, and if called as a method, it
uses the dynamically pass-in binding of |this|.
Note that the .call
See http://wiki.ecmascript.org/doku.php?id=strawman:soft_bind for the
method-API proposal.
/be
On Mar 30, 2011, at 2:11 PM, David Herman wrote:
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as
a
On Mar 28, 2011, at 10:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 27, 2011, at 11:13 AM, David Herman wrote:
To be fair, your suggestion is more moderate than de Bruijn, although it's
not clear whether you're proposing the ability to refer to shadowed bindings
of *all*
On Tue, Mar 29, 2011 at 12:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
(I think I'm the only one to use the syntax ^this in a proposal so I'm not
sure where 1,3,4 (at least using ^this syntax) came from.
Well, I wasn't sure if you meant 1 or 2, and other people had
suggested 3 and
On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote:
I agree entirely that it goes with the existing fixed implicit |this|
binding -- I just think that cuts the other way. The reason we're
having this discussion is that the existing behavior of |this| isn't
always what you want, and is hard
This is what Sam is referring to -- we've been talking about exactly such a
feature. I continue to believe that something like the ^this feature we've been
talking about is as likely to introduce bugs as it is to fix bugs. It's like
special language support for off-by-one errors.
Dave
PS A
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
This is what Sam is referring to -- we've been talking about exactly such a
feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own custom name for the |this|-parameter, so that you could
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
PS A propos of nothing, the ^this syntax probably doesn't work because of
ASI; try parsing:
x = y
^this.foo()
I specified that ^this was a lexical token so I ASI should work fine. But
you would have to say
y ^
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite
of what they are about!
Sorry to astonish you. :)
No problem!-) I was just afraid of the idea being misunderstood
or being associated with fear-inducing phrasing,
On Mar 29, 2011, at 7:28 AM, David Herman wrote:
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
This is what Sam is referring to -- we've been talking about exactly such a
feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own
On 2011-03-29, at 14:19, Allen Wirfs-Brock wrote:
I'll leave it to reader to weigh the above pros and cons. But I do have a
closing statement:
There is a decades long disagreement among designers/users of function and
object-oriented languages. OO proponents think there is something
On Mar 29, 2011, at 11:19 AM, Allen Wirfs-Brock wrote:
The original discussion in January added explicit naming and lexical scoping
of the implicit this parameter to # function declarations. In January we
didn't settle on a syntax but in March we seem to be converging on something
like:
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
JavaScript up to this point seems to have done a pretty good job of balancing
the OO and functional perspective within the language. However, I think
removing the specialness of this and the implicit this
On Mar 29, 2011, at 3:03 PM, Sam Tobin-Hochstadt wrote:
On Tue, Mar 29, 2011 at 2:19 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
JavaScript up to this point seems to have done a pretty good job of
balancing the OO and functional perspective within the language. However, I
think
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite
of what they are about!
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for automatic transformation,
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite of what they
are about!
Sorry to astonish you. :)
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for
On Mar 27, 2011, at 11:13 AM, David Herman wrote:
To be fair, your suggestion is more moderate than de Bruijn, although it's
not clear whether you're proposing the ability to refer to shadowed bindings
of *all* variables or just |this|. If it's the former, I'm *strongly*
opposed. If it's
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Overall, I really like ^this as a narrow solution to a specific real usage
problem. I'm interested in reactions and unless somebody thinks of something
that seriously torpedoes it I will probably write it up as a
On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Overall, I really like ^this as a narrow solution to a specific real usage
problem. I'm interested in reactions and unless somebody
On Mar 28, 2011, at 8:30 PM, Sam Tobin-Hochstadt wrote:
On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Overall, I really like ^this as a narrow solution to a specific real usage
function f() {} // target this binding
(function () {
function f() { // skip this binding
The line directly above introduces two bindings in two scopes. Did
you mean that both of them are skipped, or just one?
This made me feel as if I was missing something, so I went back to the
ES spec:
2011/3/26 Jeff Walden jwalden...@mit.edu:
Further, how would this interact with eval introducing (or in some systems
even removing) lexical bindings? (Or maybe eval doesn't matter if this only
If, as at
https://mail.mozilla.org/pipermail/es-discuss/2011-February/012896.html
, harmony is
Further, how would this interact with eval introducing (or in
some systems even removing) lexical bindings?
Disclaimer 1: the Berkling-style systems I'm familiar with did
not support eval, so I cannot argue from experience here
Disclaimer 2: the reason for this was that unlimited
The questions about eval look mostly unproblematic to me. In ES5-strict and
Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine
the semantics would be pretty straightforward, if problematic; but eval being
able to affect its caller's scope is problematic anyway, so
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as
2011/3/26 Claus Reinke claus.rei...@talk21.com:
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To
2011/3/26 Claus Reinke claus.rei...@talk21.com:
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection
This is an interesting idea, never heard of it before. That said, it seems a
better start for brainstorming than as an end of it. The previously-mentioned
concerns about numbering being fragile seem real to me. Further, how would
this interact with eval introducing (or in some systems even
35 matches
Mail list logo
