Phango

[Bill Baxter]

Lars Ivar Igesund wrote:
> Bill Baxter wrote:
> 
>> torhu wrote:
>>> Lars Ivar Igesund wrote:
>>>  >> Mixed case package/module names are avoided because there needs to be
>>>  >> a
>>>>> 1:1 correspondence between file names and package/module names, and not
>>>>> all file systems are case sensitive (like FAT32 and NTFS, for a couple
>>>>> widely used examples).
>>>> As I said elsewhere in the thread, other FS _are_ case sensitive, and
>>>> thus
>>>> you need to be aware of which case you use in either case, rendering the
>>>> argument moot. Early on in D history, I encountered several cases of
>>>> modules being saved on Windows, then not working on Linux with their
>>>> intended module names due to this. And this can only happen if the
>>>> Windows
>>>> programmer typed in a file name with upper case letters, even though the
>>>> module name was all lower case.
>>>>
>>> I believe Walter's point is that "all package and module names are lower
>>> case" is a simple rule that will help us avoid this problem, given that
>>> everyone does their best to adhere to the rule.  I don't know how much
>>> it matters, since I've never run into the problem myself.  But I just
>>> tried it, and it shouldn't be hard to track down the problem based on
>>> the compiler's error messages.  Not a big deal either way, it seems.
>> There is another issue.  Often a module has basically only one main
>> class in it.  If the main class is called Foo, and that's all that's in
>> the module, some version of "Foo" is the logical name for the package
>> too.  But then if you use fully qualified names you end up with
>> Package.Foo.Foo when referring to the class in the module, which just
>> look *so* silly that it's easy to forget the second Foo.  But
>> package.foo.Foo looks more reasonable, since it's clear the second to
>> last "foo" is not a class name.
>>
>> --bb
> 
> Using fully qualified class names are very seldom necessary in D, I find
> using renaming imports are much more useful. 

Ok, but then the most obvious name for the renamed import is the last 
component of the dot-separated module name:
   import Foo = Package.Name.Too.Long.Foo;
   ...
   Foo.Foo

Of course you could rename the module lower-case 'foo', but you could 
also just have named it in lowercase from the beginning.  Or you could 
come up with some other convention.

But anyway, I agree that in Tango the package names are so long that 
static import is impractical.  But for other libraries that's not the 
case, and I think what a lot of people are after here is a convention 
that's universally applicable.  I use static import all the time in my 
code because Phobos' flatter naming works well with that, and my own 
code also is usually only 1 or 2 levels deep.  But I also use renamed 
and selective imports too, depending how much stuff I plan to use from 
the module.
[As an aside I really wish I could do renamed and selective importing on 
one line, like import mod=some.long.module : Foo, Bar; ]

Saying "don't use static import" isn't a very strong argument for the 
Tango naming convention in my opinion.

> I'd like to turn your argument
> the other way round: If you do
> 
> import package.Foo;
> 
> then it make a lot of sense that you can just use your class Foo. 

If that were the only way to do imports in D, then that would make a lot 
of sense.  But we also have static, renamed, and selective imports and 
their use should be encouraged.  They help keep the top-level namespace 
clean, and help make code more readable by specifying explicitly where 
symbols are coming from.

> I
> understand that this may have been uncommon for those coming from C, but I
> know of several C++ libraries (Object oriented) using header files with
> capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't
> always this way, but changed with version 4. OI I think always did this,
> and it is 15+ years old. Indeed, its top level package is "Inventor"!
> FWIW, I think SGI and TrollTech is two of very few companies that have
> created truly good library API's in C++.

The comparison with C++ is not valid because in C++ namespaces and file 
names are decoupled.  So in C++ something like 
#include<Package/SubPackage/ClassName.h>  will generally put the 
ClassName into the Package::SubPackage namespace.  Or sometimes just the 
Package namespace.  I've never seen anyone create a 
Package::SubPackage::ClassName namespace to enclose a class called 
ClassName.  But in D you don't have a choice.  The full path always 
becomes part of the namespace.

> I could of course also pull in Java and C# as examples, but those are
> weirdly enough disregarded in this debate.

I don't remember enough about how Java imports worked to comment, and 
I've never touched C#.

--bb