If I have a module "Foo.d" and a class inside it called "Foo", the class name is unavailable in a module Bar.d that imports Foo. For example, if I say "new Foo()", D complains that Foo is a module, not a type.

I wasn't expecting that due to these statements in the D reference under Modules:

* The top level scope in the module is merged with the current scope. * When a module is imported into another module, by default all its top level declarations are available without qualification.

That would seem to imply that Foo the class becomes a top level declaration when I say:

# import Foo

I've tried "alias Foo.Foo Foo;" but that gave an error message.

Is there any way around this other than using the case trick? (The case trick being that since D is case sensitive you can call the module Foo and the class foo, or the other way around, and have access to both--with case dictating which is which.)

I have plenty of modules where the only interesting thing in the module is a single class by the same name.


-Chuck

Chuck Esterbrook wrote:

> Is there any way around this other than using the case trick? (The
> case trick being that since D is case sensitive you can call the
> module Foo and the class foo, or the other way around, and have access
> to both--with case dictating which is which.)

From the D style guide (http://www.digitalmars.com/d/dstyle.html):

****************************************************************
Module
    Module names are all lower case. This avoids problems dealing with case insensitive file systems.

Class, Struct, Union, Enum names
    are capitalized.
****************************************************************

Follow this convention and you'll never go wrong.

"Chuck Esterbrook" <Chuck.Esterbrook@gmail.antispam.com> wrote in message news:649eg1hjsa79mbdil8c7fd8ct2pubjvkoa@4ax.com...
> If I have a module "Foo.d" and a class inside it called "Foo", the class name is unavailable in a module Bar.d that imports Foo. For example, if I say "new Foo()", D complains that Foo is a module, not a type.
>
> I wasn't expecting that due to these statements in the D reference under Modules:
>
> * The top level scope in the module is merged with the current scope.

I think the word "merged" is misleading there. The imported module is seached if the symbol isn't found in the current scope but if the symbol is in the current scope it never looks at the imported module. So Foo, which exists in the current scope as a module name, stops the search and D never goes into Foo to look for more Foos.

> * When a module is imported into another module, by default all its top level declarations are available without qualification.
>
> That would seem to imply that Foo the class becomes a top level declaration when I say:
>
> # import Foo
>
> I've tried "alias Foo.Foo Foo;" but that gave an error message.

yup. That's because Foo already refers to the module. You can overload methods but you can't overload module names.

> Is there any way around this other than using the case trick? (The case trick being that since D is case sensitive you can call the module Foo and the class foo, or the other way around, and have access to both--with case dictating which is which.)

Trick? Sounds devious... Once you code in D for a little bit you get used to the style and it'll never occur to you to use caps in module names. The harder case is when you have a function called foo() in a module called foo. Then you have to actually think of a new name for one of the two.

> I have plenty of modules where the only interesting thing in the module is a single class by the same name.

Java coders will bump into that alot since in Java the module name must match the class name.

>
> -Chuck

> 
> Trick? Sounds devious... Once you code in D for a little bit you get used to the style and it'll never occur to you to use caps in module names. The harder case is when you have a function called foo() in a module called foo. Then you have to actually think of a new name for one of the two.

I just encountered this. It surprised me. When you see the line...
y=foo(x)
why does the compiler even *think* that foo could be a module name?
Isn't it obvious that it's a function?
Or is there some valid syntax
modulename()
which is ambiguous?
If this behaviour is inevitable, then it should be an error to have an identifier with the same name as the module it is in.
Think how much fun you can have if you create a module called writefln.d :-)