Re: function hoisting like var
It's not that your code is convoluted (although it is), it's that the added
complexity to parse {{...}}, backwards incompatibility of that syntax (code
generators), and the questionable aesthetics (it really is subjective) just
make it infeasible. All just to provide a hoisted-let-like functionality.
Plus, it's a dead horse that's been beaten one too many times :)
I would like ES3.x to support let functionality, but I'd rather ES3.x just
implement let statements/declarations, rather than {{...}}. I think others
would agree with me here.
I also prefer Igor's proposal more than {{...}}. And even if you solve
problematic continuations (return/continue/break), I would like them to be
generalized into first-class blocks.
-Yuh-Ruey Chen
On Wed, Aug 6, 2008 at 3:30 PM, Ingvar von Schoultz <[EMAIL PROTECTED]>wrote:
> Yuh-Ruey Chen wrote:
>
>> FWIW, I definitely like this proposal more than any convoluted var-scoping
>> block proposal.
>>
>> I just don't see the value of adding var-scoping blocks for the added
>> parser complexity, and problematic return/break/continue.
>>
>
> Unfortunately it seems people dislike the notation too much.
> But the complexity that you discuss must be supported anyway.
> Regardless whether it's written {let} or {{var}}, they both
> say the same thing, and what they say is supported in ES4.
>
> My code looks convoluted only because it's an odd trick.
> Not only does it add {let} functionality to ES3.1, it also
> strives very hard to make the tiniest possible change.
>
> That tiny code is also conclusive proof that {{var}} is
> extremely simple and has no capture problems, despite many
> vague claims to the contrary.
>
> Unfortunately it seems people dislike the notation so much,
> they prefer having no {let} functionality at all in ES3.1.
>
> --
> Ingvar von Schoultz
>
>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: function hoisting like var
Yuh-Ruey Chen wrote:
> FWIW, I definitely like this proposal more than any convoluted
> var-scoping block proposal.
>
> I just don't see the value of adding var-scoping blocks for the added
> parser complexity, and problematic return/break/continue.
Unfortunately it seems people dislike the notation too much.
But the complexity that you discuss must be supported anyway.
Regardless whether it's written {let} or {{var}}, they both
say the same thing, and what they say is supported in ES4.
My code looks convoluted only because it's an odd trick.
Not only does it add {let} functionality to ES3.1, it also
strives very hard to make the tiniest possible change.
That tiny code is also conclusive proof that {{var}} is
extremely simple and has no capture problems, despite many
vague claims to the contrary.
Unfortunately it seems people dislike the notation so much,
they prefer having no {let} functionality at all in ES3.1.
--
Ingvar von Schoultz
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: How to escape implicit 'with (this)' of a method body
On 2008-08-01, at 05:13EDT, Peter Hall wrote:
>>>
>>> In AS3, the reference to bar in the zot function would be bound to
>>> this.bar
>>
>> I don't follow. There is no `this.bar` in the class where zot is
>> defined.
>>
>
> Sorry, I said that backwards. When class foo is compiled, there is no
> member called bar, so the reference is bound to the global variable.
> Defining a member variable called bar in the subclass does not affect
> that.
I think what everyone is saying is that my model of how references in
methods are resolved is wrong. There is no implicit `with (this)` in
method bodies, the references are resolved lexically, not dynamically.
In either case, though, it seems there is no in-language way to refer
to a global that is shadowed by an instance variable. The offered
solutions assume that the implementation creates a global object that
can be used to refer to globals.
> I don't know how convention will develop in other environments but, in
> AS3, global variables are almost always declared in packages, and
> strict mode is on by default. The result is that you would always get
> a compiler error in these cases instead of an ambiguous reference.
What is the error? I don't get an error with this code:
var free = 'outer';
class Top {
function test () { return free; }
}
class Sub extends Top {
var free = 'inner';
override function test () { return free; }
}
Perhaps this is just poor practice, but it is confusing that the two
uses of `free` result in two different bindings.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
