On Thursday, February 09, 2012 14:57:08 Oliver Plow wrote:
> Hello,
> 
> I'm fighting with a strange compiler error. This here compiles and runs fine:
> 
[snip]
>
> This is a bit strange for me. Apparently, must be some kind of import problem importing Foo. But I don't see how ...

It's because you named both your module and type Foo. So, when you import Foo, Foo.z is a module-level symbol in Foo (which does not exist). You'd need to do Foo.Foo.z. If your module were named something completele different (e.g. xyzzy), then Foo.z would then be referring to your class Foo's z variable, and it would work.

Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations). Renaming your module to foo should fix your problem.

- Jonathan M Davis

Jonathan M Davis:

> Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations).

That's just a fragile work-around for a module system design problem that I didn't like from the first day I've seen D. I'll take a look in Bugzilla if there is already something on this.

Bye,
bearophile

> I'll take a look in Bugzilla if there is already something on this.

Nevermind.

Bye,
bearophile

Thanks for the answer. This means that all classes belonging to the same module must be in the same *.d file? I mean not one *.d file per class as in most languages?

Regards, Oliver


-------- Original-Nachricht --------
> Datum: Thu, 09 Feb 2012 14:18:07 -0500
> Von: "Jonathan M Davis" <jmdavisProg@gmx.com>
> An: "digitalmars.D.learn" <digitalmars-d-learn@puremagic.com>
> Betreff: Re: Compiler error with static vars/functions

> On Thursday, February 09, 2012 14:57:08 Oliver Plow wrote:
> > Hello,
> > 
> > I'm fighting with a strange compiler error. This here compiles and runs fine:
> > 
> [snip]
> >
> > This is a bit strange for me. Apparently, must be some kind of import problem importing Foo. But I don't see how ...
> 
> It's because you named both your module and type Foo. So, when you import
> Foo,
> Foo.z is a module-level symbol in Foo (which does not exist). You'd need
> to do
> Foo.Foo.z. If your module were named something completele different (e.g.
> xyzzy), then Foo.z would then be referring to your class Foo's z variable,
> and
> it would work.
> 
> Normally, it's considered good practice to give modules names which are
> all
> lowercase (particularly since some OSes aren't case-sensitive for file
> operations). Renaming your module to foo should fix your problem.
> 
> - Jonathan M Davis

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

On Thursday, February 09, 2012 14:45:43 bearophile wrote:
> Jonathan M Davis:
> > Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations).
> 
> That's just a fragile work-around for a module system design problem that I didn't like from the first day I've seen D. I'll take a look in Bugzilla if there is already something on this.

What design problem? The only design problem I see is the fact that some OSes were badly designed to be case insensitive when dealing with files, and that's not a D issue.

- Jonathan M Davis

On Thursday, February 09, 2012 22:42:17 Oliver Plow wrote:
> Thanks for the answer. This means that all classes belonging to the same module must be in the same *.d file? I mean not one *.d file per class as in most languages?

There is no connection between modules and classes other than the fact that they have to go into modules (like all code in D does). You could have 1000 public classes in the same module if you wanted to (though obviously that would be a maintenance nightmare). structs, classes, and free functions can all mix in a single module, and the module's name can be anything you want as long as it's a valid symbol name. It doesn't have to match any of the symbol names within tho module.

And I'd dispute the "most languages" bit. The only languages that I'm aware of which make such a connection are Java and C#, and I'm not even sure that C# is that strict about it (it's been a while since I programmed in C#). I believe that the "one public class per file" requirement is something that Java introduced and which is not common among programming languages in general.

- Jonathan M Davis

On 2/10/2012 6:42 AM, Oliver Plow wrote:
> Thanks for the answer. This means that all classes belonging to the same module must be in the same *.d file? I mean not one *.d file per class as in most languages?
>
> Regards, Oliver
>

Actually, yes. You can't have two modules of the same name. In D, 'module' is synonymous with 'file'. However, you also have packages at your disposal. And 'package' is synonymous with 'directory'. So you can keep one class per module (should you choose to do so) and group them all under a common package name.

So given the directory foo with two files:

foo
 - bar.d
 - baz.d

You would have this in bar.d:

module foo.bar;

And then in baz.d

module foo.baz

Then you can put your Bar class in bar.d and your Baz class in baz.d if that's the approach you prefer.

On 2/10/2012 1:00 PM, Mike Parker wrote:
> On 2/10/2012 6:42 AM, Oliver Plow wrote:
>> Thanks for the answer. This means that all classes belonging to the
>> same module must be in the same *.d file? I mean not one *.d file per
>> class as in most languages?
>>
>> Regards, Oliver
>>
>
> Actually, yes. You can't have two modules of the same name. In D,


And I should append "in the *same package*". Modules in different packages can have the same name.


> 'module' is synonymous with 'file'. However, you also have packages at
> your disposal. And 'package' is synonymous with 'directory'. So you can
> keep one class per module (should you choose to do so) and group them
> all under a common package name.
>
> So given the directory foo with two files:
>
> foo
> - bar.d
> - baz.d
>
> You would have this in bar.d:
>
> module foo.bar;
>
> And then in baz.d
>
> module foo.baz
>
> Then you can put your Bar class in bar.d and your Baz class in baz.d if
> that's the approach you prefer.
>

On 09/02/12 23:03, Jonathan M Davis wrote:
> On Thursday, February 09, 2012 14:45:43 bearophile wrote:
>> Jonathan M Davis:
>>> Normally, it's considered good practice to give modules names which are
>>> all lowercase (particularly since some OSes aren't case-sensitive for
>>> file operations).

That's just a Walter thing, and it's bollocks. There's no need to use all lower case.

>>
>> That's just a fragile work-around for a module system design problem that I
>> didn't like from the first day I've seen D. I'll take a look in Bugzilla if
>> there is already something on this.
>
> What design problem? The only design problem I see is the fact that some OSes
> were badly designed to be case insensitive when dealing with files, and that's
> not a D issue.
>
> - Jonathan M Davis

You can argue this either way. There are not many use cases for having two files differing only in case.

On 02/10/12 15:18, Don Clugston wrote:
> On 09/02/12 23:03, Jonathan M Davis wrote:
>> On Thursday, February 09, 2012 14:45:43 bearophile wrote:
>>> Jonathan M Davis:
>>>> Normally, it's considered good practice to give modules names which are all lowercase (particularly since some OSes aren't case-sensitive for file operations).
> 
> That's just a Walter thing, and it's bollocks. There's no need to use all lower case.

No, having non-lower case filenames would just lead to problems. Like different
modules being imported depending on the filesystem being used, or the user's
locale settings.
There's no need for upper and mixed case module file names.

artur