Phango

[Lars Ivar Igesund]

Bill Baxter wrote:

> Lars Ivar Igesund wrote:
>> 
>> 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; ]

I think it does? At least I think the spec allows it.

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

Never liked static imports :P The static keyword is probably part of that :)

> 
>> 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#.

I'll withdraw C# from the discussion, as I don't know all aspects well
enough. Java however requires module names to equal class names, whether
they are lowercased or CamelCased. I may agree that such comparisons
possibly aren't entirely applicable though, considering modules in D are
much more important than in those languages. They are encapsulated entities
themselves after all. Which, if used as such, would imply that casing
should be the same as for classes and structs.

I'll accept this match to end with a remis though, so I can stop posting
about this :)


-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango