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 Fri, Apr 11, 2008 at 12:48 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Ah! Of course.
The natural thing to spec would be that the text of the expression
would be part of (all of?) the message of the exception object
in the 1-arg case.
Or would it be better for AssertionError to have
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.
My views on this are:
- There should be only *one* syntax for specifying namespaces in definitions.
It shouldn't be
ns::foo = xyz
in one place (object initializers) and
ns var foo = xyz
someplace else (variable definitions).
- The historical reason I chose the syntax
ns var foo = xyz
for
