Namespace variable bug

[d.healey]

I have a script with a const var called width. I also have a library I'm including, that library has a namespace ui inside the namespace is a function that uses a var called width. This is causing a conflict and producing an already declared error.

[Christoph Hart]

const var width = 2;

namespace D
{
    const var width = 5;
    
    Console.print(width);
}

This works here (prints 5). Can you make a minimal example that's causing the error?

[d.healey]

const var width = 2;

namespace D
{
	
    var width = 5;
    
    Console.print(width);
}

The error is Line 6, column 12: Identifier width is already defined as const variable Does this imply that in your version it is actually using the variable outside of the namespace?

[Christoph Hart]

No, you can't declare simple var variables in a namespace (it will be ignored and just put into the root namespace where it clashes with the const var of the same name). Namespaces are only relevant for const var and reg slots. There's actually no reason to use a var type, except for when you need more than 32 mutable variables in one namespace (or in standard Javascript functions).

And in my example it prints 5 because the member of the namespace has priority EVEN when the namespace is not explicitly defined (that's the way how C++ works).

[d.healey]

Ah I understand now. I shall use a reg in my case then :)

What's the advantage of using local with getComponent?

[Christoph Hart]

the scope of local is limited to the inline function, so it's better encapsulated (otherwise you would keep a reference to the widget around and it might cause subtle bugs if you use that name for multiple factory methods).

[d.healey]

I get an error with this version too

const var width = 2;

namespace D
{
    reg width = 5;
    
    Console.print(width);
}

Line 6, column 15: Identifier width is already defined as const variable

[Christoph Hart]

Hmm, it seems like this is an tiny oversight in the parsing code. Is this a real world problem, otherwise I'd like to ignore this edge-case :)

[d.healey]

Well it came up in a real world project but I just changed the name of the variable so I think it's safe to acknowledge it and ignore it