Namespaces on definitions
I agree. I don't see why there should be multiple syntaxes that are as concise as each other and both have about equal precedent (AS3 vs. E4X). If in some futuer spec, properties can inhabit multiple namespaces, then we can consider the |ns1 ns2 ... var foo| syntax again.
On Apr 16, 2008, at 2:50 AM, Yuh-Ruey Chen wrote:
I agree. I don't see why there should be multiple syntaxes that are as concise as each other and both have about equal precedent (AS3 vs.
E4X). If in some futuer spec, properties can inhabit multiple namespaces,
then we can consider the |ns1 ns2 ... var foo| syntax again.
The syntaxes are not equally concise, not only because :: is heavier
visually and in terms of keyboard input (two shifted chars) than
spaces. Consider
ns var foo, bar;
vs.
var ns::foo, ns::bar;
It's true you can't distribute one type across several variables:
var foo:T, bar:T;
but that's not a reason to restrict namespace syntax per se.
Cases of ns including public, protected, private, and internal may be
the most useful ones for this distributive syntax, but are those
namespaces? Either way, the ns var foo syntax is more concise.
Here are some other interesting cases involving destructuring patterns.
Qualified syntax:
var {x = ns::x, y = ns::y, z = ns::z}: {x:A, y:B, z:C } = ... var [ns::x, ns::y, ns::z}: [A, B, C ] = ...
Attribute syntax:
ns var {x, y, z}: {x:A, y:B, z:C} = ... ns var [x, y, z]: [A, B, C] = ...
To my eye the latter are cleaner and clearer. There is another sense in which I think the attribute syntax is better. The identifier is the short name of the binding and having it cleanly delineated from the namespace part of the name makes the meaning of the binding clearer.
I agree that having two ways of naming properties is unfortunate, but it¹s probably unavoidable. I tried the opposite approach of using var¹ and const¹ forms in object initializers to get rid of some uses of qualified names there. But in the end, that is just noisier. I¹ve resigned myself to the view that ³N::X² is the way to name dynamic properties, and ³N var X² (and the like) is the way to name fixed properties.
There is an old downside to the attribute syntax: You can't put line breaks between the attributes and the definition, even though it's tempting to do so on long lines. Otherwise you silently change the meaning of existing ES3 code like:
foo var bar = 3
Waldemar
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 ES4 was that I allowed the same definition to simultaneously go into several namespaces: ns1 ns2 ns3 var foo = xyz would create ns1::foo, ns2::foo, and ns3::foo, which would be aliases of the same variable (not three different variables). ES4 doesn't support that any more, so this reason goes away and the issue can be reconsidered.
Now that the issue has been brought up, I'm warming up to the syntax var ns::foo = xyz everywhere. It's simpler to remember. It doesn't match Java, but if that were a goal then we should first change our type annotation syntax to that of C++ and Java.
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 ES4 was that I allowed the same definition to simultaneously go into several namespaces: ns1 ns2 ns3 var foo = xyz would create ns1::foo, ns2::foo, and ns3::foo, which would be aliases of the same variable (not three different variables). ES4 doesn't support that any more, so this reason goes away and the issue can be reconsidered. Now that the issue has been brought up, I'm warming up to the syntax var ns::foo = xyz everywhere. It's simpler to remember. It doesn't match Java, but if that were a goal then we should first change our type annotation syntax to that of C++ and Java. Waldemar Lars Hansen wrote: >> -----Original Message----- >> From: zeppieri at gmail.com [mailto:zeppieri at gmail.com] On >> Behalf Of Jon Zeppieri >> Sent: 11. april 2008 09:50 >> >> ... >> The question is: why not apply it to classes, too? >> >> By the way, I was wrong about the grammar allowing >> >> var public::count = ... >> >> in classes. It doesn't. But why not allow it there and consider it >> canonical? (Doesn't 'var' also indicate that the property is a >> fixture in a class definition, too? It's not part of the name, >> anyway.) > > 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 "right" syntax for variables. The syntax > > var private::key, private::foo, public::x, private::bar; > > is certainly workable and unambiguous but > > public var x; > private var key, foo, bar; > > works better for me, because the access control is visible and > separated from the names, because each phrase is shorter, and > because I'm guaranteed to separate my privates from my publics. > > Classes are sort of funny since you can consider a property name > in a class both as a property on the instance (o.id) but also > just as a scoped variable, inside all the methods of the class. > If you're *really* into Java the former case disappears completely > because there will be getter/setter pairs for everything ;) so the > "scoped variable" case is completely dominant. I'm not sure > that's wrong, and I think a variable declaration syntax is > more natural than an object property syntax. > > (The syntax of field names in object initializers, on the other hand, > is a consequence of how that syntax has evolved.) > > Matters of taste? To an extent. But preserving "brain print" from > other languages (Java, Python) is not unimportant, it's one of the > principles that have been used in designing the language. > > --lars