On Fri, Apr 11, 2008 at 11:04 AM, Lars Hansen [EMAIL PROTECTED] wrote:
Right, I get that, and Brendan's point was a good one. I was
just thrown by the fact that I hadn't seen an example of
class A {
var public::count = 10;
}
rather than
class A {
public var
On Fri, Apr 11, 2008 at 12:17 PM, Lars Hansen [EMAIL PROTECTED] wrote:
One motivation is that programmers are likely to prefer the Java-like
syntax where the namespace (in its role as access control) shows
up early:
public var count =
private var key =
I really think this is the
On Fri, Apr 11, 2008 at 1:05 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
Yep, I agree with this, too. I certainly wouldn't want to mandate
var public::x
in classes and wouldn't really want to write it myself. But there's
some value in having a single, canonical syntactic form that
On Apr 11, 2008, at 10:22 AM, Lars Hansen wrote:
(It _is_ an indication that the syntax used in
the object initializers is not fully general, though, since it only
allows simple identifiers in the namespace position. Sigh.)
I've argued that JS's literal property identifiers in object
On Apr 11, 2008, at 12:51 PM, Lars Hansen wrote:
There might be a slight misunderstanding here. In my example, the
name C.ns is constant, not a general expression; C needs to be a
class, and ns needs to be a static namespace definition inside that
class (suitably available).
Oh, ok.
On 4/10/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
var o = { null var count = 100, ... };
Sorry: two syntactic mistakes, here, one of which is interesting.
The boring one is my use of '=' rather than ':'.
But after reading the object initializer draft, I see that, if the
intent of the
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 10. april 2008 21:31
To: Lars Hansen
Cc: liorean; es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On 4/10/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
var o = { null
On Thu, Apr 3, 2008 at 8:34 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
... treats the environment as if it were a datum. I know that in the
ES3 spec all bindings are referred to as properties of objects, but
activation objects are only notional entities. The current ES4
proposal seems to
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 3. april 2008 21:35
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: Strict mode recap
Let me turn it around.
The syntax ns::v is in the language, for constant
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Let me turn it around.
From my perspective, it isn't an E4X vs. ES4 distinction;
it's a looking up a property of a first-class object vs.
using a local variable (or, if you prefer, looking up a
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of liorean
Sent: 4. april 2008 10:47
To: es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On 04/04/2008, Lars Hansen [EMAIL PROTECTED] wrote:
Your comment about inhibiting static analysis
On Fri, Apr 4, 2008 at 11:30 AM, Lars Hansen [EMAIL PROTECTED] wrote:
I don't get it.
Your comment about inhibiting static analysis isn't right; if ns::x is a
name then either ns is known to be constant at compile time or not, and
if it is, then nothing prevents early binding. ES3
-Original Message-
From: Jon Zeppieri [mailto:[EMAIL PROTECTED]
Sent: 4. april 2008 11:02
To: Lars Hansen
Cc: liorean; es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On Fri, Apr 4, 2008 at 12:57 PM, Lars Hansen
[EMAIL PROTECTED] wrote:
(BTW I believe that locally
On Fri, Apr 4, 2008 at 1:25 PM, Lars Hansen [EMAIL PROTECTED] wrote:
I hope the forthcoming spec on names will clarify
this, so I suggest we hold off arguing about this particular point for
the moment.
Happily.
You can argue, and I think you are arguing, that there is no utility in
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 4. april 2008 11:38
To: Lars Hansen
Cc: liorean; es4-discuss@mozilla.org
Subject: Re: Strict mode recap
I disagree, based on my experience analyzing uses of eval in
scripts
On Fri, Apr 4, 2008 at 1:45 PM, Lars Hansen [EMAIL PROTECTED] wrote:
That could be true. But it could also be the case that people
find that it is easier to say
var x = ...
var y = ...
var n = x // but could be y
...
// n may change here by assigning another string to it
On Fri, Apr 4, 2008 at 11:24 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
(and the latter does not handle shadowing, for better or worse).
Heh. Someone should revive Mark Miller.
[startles] What? I'm awake. Can someone summarize the issue in a
self-contained manner?
--
Text by me above is
On Fri, Apr 4, 2008 at 2:42 PM, Mark Miller [EMAIL PROTECTED] wrote:
On Fri, Apr 4, 2008 at 11:24 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
(and the latter does not handle shadowing, for better or worse).
Heh. Someone should revive Mark Miller.
[startles] What? I'm awake. Can
On Wed, Apr 2, 2008 at 11:15 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Is this already in AS3? If so, is it often used?
The syntax comes from E4X, which is incorporated into AS3 and
Spidermonkey. Try this in Firefox:
script type=text/javascript;e4x=1
var x = ns:p
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 3. april 2008 10:10
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On Wed, Apr 2, 2008 at 11:15 PM, Lars Hansen
[EMAIL PROTECTED] wrote
On 4/3/08, Lars Hansen [EMAIL PROTECTED] wrote:
package X {
namespace myns;
class C {
myns var v = 37;
}
var x = myns;
var y = v;
print((new C).x::[y]);
}
This does print '37' if compiled with ASC and run through
the Tamarin VM.
This is like
On 04/04/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
This is like the E4X example in one crucial respect: in both cases,
you're accessing a property of a first-class object. I'm not arguing
against this use of computed names. I don't see any significant
difference between the above and:
On 4/3/08, liorean [EMAIL PROTECTED] wrote:
On 04/04/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
function foo(name) {
...
return null::[name];
}
... treats the environment as if it were a datum. I know that in the
ES3 spec all bindings are referred to as
On 4/4/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
eval has a real use: runtime code generation. (This does not require
dynamically scoped eval, but that's beside the point here.)
Uh, I meant lexically scoped eval, of course...
___
Es4-discuss
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
Sent: 31. mars 2008 20:09
To: Waldemar Horwat; es4-discuss@mozilla.org
Subject: RE: Strict mode recap
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED
On 3/31/08, Lars Hansen [EMAIL PROTECTED] wrote:
Having thought more about this, we may get away with less
draconian measures for lexically scoped eval -- it's enough
to simply decree that eval may not add bindings to the
caller's binding object in strict mode (a simple run-time check,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 2. april 2008 17:51
To: Lars Hansen
Cc: Waldemar Horwat; es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On 3/31/08, Lars Hansen [EMAIL PROTECTED] wrote:
Having
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
Lars, does this mean that expr::[expr] can't introduce
lexical bindings? Or: in strict mode, it can't, but in
standard it can?
It can't introduce bindings; it's just a name.
I meant something like:
var foo::[bar] = baz;
My
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 2. april 2008 19:06
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
Lars, does this mean
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
I meant something like:
var foo::[bar] = baz;
My objection to expr::[expr] in earlier messages was based on
the assumption that these computed names could be used on the
left-hand side of an assignment expression -- which, I'm
Mark Miller wrote:
- Disable FunctionObject.arguments (not actually in ES3 but
woefully used in practice)
This is an interesting one, since disallowing it would mean that
the ES3.1 and ES4 specs would have to re-allow it so that they could
explicitly disallow it :)
Yes. It's also
-Original Message-
From: Mark Miller [mailto:[EMAIL PROTECTED]
Sent: 31. mars 2008 21:36
To: Lars Hansen
Cc: Waldemar Horwat; es4-discuss@mozilla.org
Subject: Re: Strict mode recap
- Disable FunctionObject.arguments (not actually in ES3 but
woefully used in practice
On Apr 1, 2008, at 12:22 PM, Lars Hansen wrote:
Strangely, built-in functions were exempt from the mechanism (ch 15
intro); I don't know if that's a pragmatic issue (implementation
reasons)
or a security issue.
I don't recall, but it doesn't matter for natives, AFAICT.
The mechanism is not
- Disable FunctionObject.arguments (not actually in ES3 but
woefully used in practice)
This is an interesting one, since disallowing it would mean that
the ES3.1 and ES4 specs would have to re-allow it so that they could
explicitly disallow it :)
Yes. It's also an interesting
34 matches
Mail list logo
