Namespaces on definitions
waldemar at google.com
Fri Apr 11 19:52:44 PDT 2008
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.
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,
> 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.
More information about the Es4-discuss