We discussed these issues at today's ES3.1 conference call and arrived at a new
plan of record:
1) We concluded that the present diversity of semantics of block nested
function declarations among browser implementations probably cannot be replaced
with a standard semantics without significant
On Thu, Jul 10, 2008 at 11:05 AM, Brendan Eich [EMAIL PROTECTED] wrote:
So what would this program print in ES3.1?
const C = 42;
function f(x, y) {
const C = 33;
if (x) {
const C = 21;
return eval(y);
}
return C;
}
print(f(true, C));
21
What does it print in
PROTECTED] On Behalf Of Brendan Eich
Sent: Thursday, July 10, 2008 1:45 PM
To: Mark S. Miller
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org; Herman Venter
Subject: Re: Update on ES3.1 block scoped function declarations
On Jul 10, 2008, at 1:28 PM, Mark S. Miller wrote:
On Thu, Jul 10, 2008 at 11:05
On Jul 10, 2008, at 2:03 PM, Brendan Eich wrote:
On Jul 10, 2008, at 1:58 PM, Allen Wirfs-Brock wrote:
Maybe, I’m missing something subtle, but 21 is clearly the right
answer and is what I believe is specified by the version of
section 10 that I sent out yesterday regardless of the scoping
block scoped function declarations
On Jul 10, 2008, at 1:58 PM, Allen Wirfs-Brock wrote:
Maybe, I'm missing something subtle, but 21 is clearly the right answer and is
what I believe is specified by the version of section 10 that I sent out
yesterday regardless of the scoping of block nested
On Thu, Jul 10, 2008 at 2:51 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
I see, yes there is a potential eval tax. If I thought this was really a
concern (and as you say, we already have the issue for catch and such) I'd
be more inclined to fiddling with the scoping rule of eval rather
On Jul 10, 2008, at 3:28 PM, Mark S. Miller wrote:
On Thu, Jul 10, 2008 at 2:51 PM, Allen Wirfs-Brock [EMAIL PROTECTED]
wrote:
I see, yes there is a potential eval tax. If I thought this was
really a concern (and as you say, we already have the issue for
catch and such) I'd be more
On Jul 10, 2008, at 3:28 PM, Mark S. Miller wrote:
On Thu, Jul 10, 2008 at 2:51 PM, Allen Wirfs-Brock Allen.Wirfs-
[EMAIL PROTECTED] wrote:
I see, yes there is a potential eval tax. If I thought this was
really a concern (and as you say, we already have the issue for
catch and such) I'd be
Brendan,
You're beating a dead horse here. If this call to eval is allowed, the only
reasonable answer is 21. All that means is that you must be able to recreate
the bindings if the function uses eval. Unless you're proposing to take
block-scoped declarations out of ES4, what's the harm
-scoped declarations out of ES4, what's the harm with
ES3.1 having a compatible subset of them?
The harm is of two kinds:
1. That ES3.1 will be pushed through Ecma standardization this
calendar year, then to ISO fast track, with zero implementations.
2. That ES3.1 spec work, using and extending
Follow up:
The RI allows typed redeclarations providing the type is not double.
This works:
// var x:double = 7
// delete x
var x:boolean = true
delete x
var x:string = there
delete x
var x:boolean = false
delete x
var x = false
delete x
But uncomment the first declaration and you get:
To: Jeff Dyer
Cc: es4-discuss Discuss
Subject: Re: Multiple declarations
Follow up:
The RI allows typed redeclarations providing the type is not double.
This works:
// var x:double = 7
// delete x
var x:boolean = true
delete x
var x:string = there
delete x
var x:boolean = false
Works for me in the RI:
var x = 10; var x = 20; print(x)
20
As it should.
Jd
On 5/1/08 4:07 PM, Michael O'Brien wrote:
Is the following valid?
var x = 2
var x = 3
The ES4 RI prevents this. ASC redefines x.
What should this do?
Michael
Jeff Dyer wrote:
Works for me in the RI:
var x = 10; var x = 20; print(x)
20
As it should.
Could be an old build? Check one of the snapshots.
http://buildbot.ecmascript.org/es4/waterfall
-Graydon
___
Es4-discuss mailing list
Thanks - a new build fixed it.
Michael
On May 1, 2008, at 4:14 PM, Graydon Hoare wrote:
Jeff Dyer wrote:
Works for me in the RI:
var x = 10; var x = 20; print(x)
20
As it should.
Could be an old build? Check one of the snapshots.
http://buildbot.ecmascript.org/es4/waterfall
Question about declarations:
Consider:
print(Shape.x)
public class Shape { public static var x = 1; }
print(Shape.x)
fun()
function fun() { print(fun); }
In the RI this prints:
undefined
1
fun
In ASC this prints:
1
1
fun
What happens in the RI is the class declaration seems to occur where
Jon, thanks. Any thoughts on the original post?
Question about declarations:
Consider:
print(Shape.x)
public class Shape { public static var x = 1; }
print(Shape.x)
fun()
function fun() { print(fun); }
In the RI this prints:
undefined
1
fun
In ASC this prints:
1
1
fun
post?
Question about declarations:
Consider:
print(Shape.x)
public class Shape { public static var x = 1; }
print(Shape.x)
fun()
function fun() { print(fun); }
In the RI this prints:
undefined
1
fun
In ASC this prints:
1
1
fun
What happens in the RI is the class
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael O'Brien
Sent: 15. april 2008 15:06
To: Jeff Dyer
Cc: es4-discuss Discuss; Jon Zeppieri
Subject: Re: Declarations
Jeff,
Can I tease out a bit more detail. I'm not sure I agree with
what
and order of execution are different.
I prefer the current es4 behavior because static class initialization
code can predictably
use lexically scoped values. And it behaves like var declarations.
Michael O'Brien
On Apr 15, 2008, at 12:13 PM, Lars Hansen wrote:
-Original Message-
From
Michael O'Brien wrote:
As a follow up, the following somewhat surprised me.
{
let b = 1
{
function fun() {
print(CALL: + b)
}
}
}
fun()
gives:
**ERROR** EvalError: uncaught exception: ReferenceError: unresolved
lexical reference
the declaration at compile time and doing
the initialisation at run time to preserve the relation with control
flow. (As I discussed in [1].)
Isn't it better to do what SpiderMonkey does for regular function
declarations in statements, as a lowest-common-denominator for how
widely the function
InterType Declarations
InterType Declarations are a useful Iand popular) way of adding
functionality to an object, usually to the prototype of a constructor.
Lets say I have a class Widget that I want to borrow from:
class Widget {
private function Widget(){}
static {
getByNode
23 matches
Mail list logo
