On Wed, 19 Jan 2011 12:57:42 +0200, spir <denis.s...@gmail.com> wrote:
Because when a module defines a type Foo (or rather, it's what is exported), I like it to be called Foo.d. A module called doFoo.d would certainly mainly define a func doFoo. So, people directly know what's in there (and this, from D's own [supposed] naming rules :-). Simple, no?
I actually tried this convention for a project. It turned out a not very good idea, because if you want to access a static member or subclass of said class, you must specify the type twice (once for the module name, and another for the type) - e.g. "Foo.Foo.bar()".
Besides, it's against the recommended D code style convention: http://www.digitalmars.com/d/2.0/dstyle.html
-- Best regards, Vladimir mailto:vladi...@thecybershadow.net
