Yes, Dave Herman already mentioned that, and I replied with this:
While this is true, this is far less of a problem than opt-in local
scoping, because the errors with opt-out local scoping are always going
to be local to the block/function the variable was assigned in.
Because of this, I believe
With this proposal you just get the dual problem: You think you're assigning
to an outer-scope variable while in fact you're creating and later discarding a
local variable. This would just flip the confusion you worry about to the
other case without eliminating it.
ES proposals already provid
Mark S. Miller wrote:
> Since ES is not an expression language, it's useful to divide the question
> into
>
> * TC for expressions
>expr equiv (function(){return expr;})()
>ES violations: this, arguments.
>'this' breakage can possibly be addressed with '.bind(this)' as in
> my previous
On Fri, Aug 29, 2008 at 6:45 PM, Felix <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> Also, you seem to be asking for an explicit way to say, "this variable
>> does not respect Tennent correspondence; I know I am doing this and I
>> have a good reason" --
>>
>>
>> http://gafter.blogspo
[EMAIL PROTECTED] wrote:
> Also, you seem to be asking for an explicit way to say, "this variable
> does not respect Tennent correspondence; I know I am doing this and I
> have a good reason" --
>
>
> http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html
I'm suspicious
On 2008-08-28, at 16:52EDT, Brendan Eich wrote:
> On Aug 28, 2008, at 1:23 PM, P T Withington wrote:
>
>> I'd like to have a syntax where this is _not_ implicitly bound. One
>> idea would be to riff on default arguments:
>>
>> function example (receiver=this, ...
>
> Why wouldn't you use |this|
On Aug 28, 2008, at 2:59 PM, Ingvar von Schoultz wrote:
> Dave Herman wrote:
>> Reformed `with' depended on type annotations and structural type
>> syntax,
>> which are undergoing discussion. So I think reformed `with' is up
>> in the
>> air for now.
>
> I find it odd that reformed |with| requ
Dave Herman wrote:
> Reformed `with' depended on type annotations and structural type syntax,
> which are undergoing discussion. So I think reformed `with' is up in the
> air for now.
I find it odd that reformed |with| required such exact type
annotations, when nothing else does. It would seem t
On Thu, Aug 28, 2008 at 12:29, Dave Herman <[EMAIL PROTECTED]> wrote:
>> Would that really satisfy Erik's use case? He seemed to think that
>> doing, at the top level --
>>
>> var global = this;
>>
>> function foo() {
>>global.bar = 3;
>> }
>>
>> is vulnerable to some ${person} going --
>>
Yuh-Ruey Chen wrote:
> Well we're all discussing radical new syntaxes (I'm looking at you,
> Ingvar), I might as well propose my own.
Radical? I find my proposal far less radical than, for example, the
Java classes discussed elsewhere.
With Java classes, a paradigm is chosen for you. My sugar emb
On Aug 28, 2008, at 1:23 PM, P T Withington wrote:
> I'd like to have a syntax where this is _not_ implicitly bound. One
> idea would be to riff on default arguments:
>
>function example (receiver=this, ...
Why wouldn't you use |this| for the parameter name? We did for type-
annotating |thi
On 2008-08-28, at 15:47EDT, Brendan Eich wrote:
> Indeed, Doug Crockford proposed at the January TC39 meeting this
> year to make 'this' act like a lexically bound variable, with the
> only magic to it applying to the case of obj.method() call
> expressions (and variatons, obj[name] where na
On Aug 28, 2008, at 12:14 PM, Dave Herman wrote:
> I interpreted Erik's point to be that the binding of `this' is not
> lexically scoped, so it would be useful to have a lexically scoped
> variable initially bound to the global object. IOW, if I write:
>
> this.print("blah blah blah")
>
> and
> Cool. Would there be a 'global' for each module (for some
> interpretation of "module" but assuming each module has its own
> separate top-level lexical scope, as appears to be the growing
> concensus)?
My intention was for the `use lexical scope' mini-proposal to be
orthogonal to any module pr
On Aug 28, 2008, at 10:36 AM, Yuh-Ruey Chen wrote:
> I've taken a look at that, and while it does address free
> variables, I'd
> still rather not have to sprinkle redundant |var|s everywhere.
Those vars are helpful to some readers, who otherwise have to learn
the Python/Ruby/TCL model and lo
On Thu, Aug 28, 2008 at 12:14 PM, Dave Herman <[EMAIL PROTECTED]> wrote:
>> For what value of "global" should the "global" keyword be global? };->
>
> I interpreted Erik's point to be that the binding of `this' is not lexically
> scoped, so it would be useful to have a lexically scoped variable ini
> For what value of "global" should the "global" keyword be global? };->
I'm not sure if this is what Erik meant, but my intention was just that
there's a variable bound in the standard library called `global' that's
bound to the global object. The only reason I suggested the name
`global' was
> Dave, I really like the lexical scope proposal. However, I do find
> the sections regarding the global a bit confusing. Are the following
> assumptions correct?
If we assume there is no standard library function called `print'...
> this.print = function(s) { ... };
Then this dynamically ad
global as speced for ES4 was equivalent to this in global scope.
There are several use cases for having global. Most of them involves
some kind of reflection. For example finding all global functions
that start with 'test' or finding out if there is an object called
'google.gears.factory'. Anot
Dave Herman wrote:
> I think you're still going to have the same subtleties as hoisting with
> this proposal, since all the variables assigned to in the block will be
> in scope for the whole block; so they'll be `undefined' before being
> assigned to and there will still be the same closure haz
On Thu, Aug 28, 2008 at 9:44 AM, Erik Arvidsson
<[EMAIL PROTECTED]> wrote:
> I hope we can still have "global" in Harmony. It is ugly to have to do:
> const global = this;
> and rely on that no one moves that code into a closure with a different
> "this".
For what value of "global" should the "g
I hope we can still have "global" in Harmony. It is ugly to have to do:
const global = this;
and rely on that no one moves that code into a closure with a different "this".
Dave, I really like the lexical scope proposal. However, I do find
the sections regarding the global a bit confusing.
On 2008-08-28, at 09:09EDT, Dave Herman wrote:
> As for free references, what can you do with a free variable? If you
> mean you want a way to look something up in the global object, then
> use `this.id' or `this[expr]' (or `let global = this' followed by
> global.id/global[expr]).
>
> It mi
> I like this, but wouldn't you want to provide escapes, like "reformed
> with" and/or a way to declare an individual reference to be free?
Reformed `with' depended on type annotations and structural type syntax,
which are undergoing discussion. So I think reformed `with' is up in the
air for n
On 2008-08-28, at 07:52EDT, Dave Herman wrote:
> Lexical scope is in the air. :) Please take a look at the lexical
> scope proposal on the wiki and offer any comments or suggestions:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope
>
> Essentially, the above is a less radica
I agree with you 100% that JavaScript /almost/ gets lexical scope right
and that we should try to eliminate that "almost" as much as we can. I
don't, however, believe that the right solution is Python's implicit
binding semantics.
> where everything assigned in ... results in a variable local t
Well we're all discussing radical new syntaxes (I'm looking at you,
Ingvar), I might as well propose my own.
One thing about JavaScript that has always really bothered me (and
probably several of you) is how JavaScript has opt-in local scope,
rather than opt-out local scope. That is, in order to h
27 matches
Mail list logo
