Phango - questions

[Bill Baxter]

Sean Kelly wrote:
> Bill Baxter wrote:

Excellent flame-free technical post addressing the issues Sean.  Thanks.

>> The Tango convention may be better for all I know, but I don't recall 
>> hearing any compelling arguments in favor of why a change was needed. 
>> If they were given and I just forgot them, then sorry.  I do recall 
>> hearing unsubstantiated claims like "we found it was better" or "we 
>> found the phobos convention to be insufficient" etc, but I don't 
>> recall any actual good arguments that made me go "hmm ah, yes 
>> indeed".  Anyway given that this topic continues to come up, it seems 
>> it would be a good idea to collect all these reasons on a page over at 
>> tango.dsource.org.
> 
> I think some of the reasons may be there already, but the page is broken 
> (for me anyway) so I can't tell you where to look.  I'm not sure if it 
> helps, but I resisted the idea of CamelCase module names when we began 
> working on Tango, possibly because I come from a C/C++ background.  But 
> as Tango has grown I've come to appreciate the readability that the 
> scheme provides.  For example, many of the module names in Tango are 
> multi-word combinations: DeviceConduit, MemoryConduit, EndianProtocol, 
> VirtualFolder, etc.  I feel that eliminating the caps in these names 
> would render them largely unreadable: deviceconduit, memoryconduit, 
> endianprotocol, virtualfolder...  The C/C++ way would be to find some 
> abbreviated form instead, but I hesitate to think that such names would 
> be more clear.

I agree that deviceconduit is atrocious.
But the official C++/STL/Boost way is to use underscores:
    #include <hash_map>
    #include <boost/shared_ptr.hpp>
    etc..

So it could be device_conduit.

But then again as you mention below, in C++/STL/Boost the naming 
convention for files *and* classes *and* methods is lowercase w/ 
underscores.  So you could say the file names are just being consistent 
with the class names.

> I suppose one could argue that following the Java approach in Tango 
> results in unneeded redundancies, such as the DeviceConduit module 
> containing a DeviceConduit class, but again, I would argue that choosing 
> an arbitrary name to avoid these redundancies would reduce clarity.  As 
> it is, I know that if I want to use a DeviceConduit in my app, I just 
> have to import tango.io.DeviceConduit.  There is no need to remember 
> that the class actually lives in tango.io.blah instead.

That does seem useful.  But is that true for every public class?  It may 
be working in Tango, but generally D doesn't really lend itself to 
Java's one-file==one-class.  (because D's only way to achieve 'friends' 
is to put two classes in the same file).  Also in Tango I see you have 
tango.math.Math which doesn't contain any class called "Math".

> As for capitalization being confusing for people using case-sensitive 
> vs. case-insensitive filesystems, I suppose this is a problem I have 
> simply never been exposed to.  D is a case-sensitive language, so I 
> would expect people using D to not make mistakes regarding 
> capitalization, particularly when the capitalization in this case 
> follows a simple and established convention (even if that convention 
> doesn't match what is in the D style guide).  Has this truly been a 
> problem?

Yeh, I don't really understand the fuss either.  I use C++ libraries 
that have mixed case headers all the time on Windows, and the exact same 
issues apply as far as I know.  A lot of big, well-respected libraries 
use this, such as Qt and OpenSceneGraph.  On the other hand wxWidgets 
doesn't.  They use the randomized compression algorithm you speak of to 
make a short name out of a long name.  Oooh I hate that.

> Finally, I'll admit to being a bit baffled about what the big deal is 
> anyway.  The C/C++ standard library uses lowercase for /everything/, 
> type names included, and I've yet to see someone complain to the various 
> committees about this, even when third party libraries for the same 
> language follow a different convention.  And things are even worse in 
> C++ because the library relies on specifically named typedefs to 
> operate, so the convention there is viral by necessity.

I've heard complaining.  I've even been a complainer (before I started 
liking lower_case names :-P).  But I never felt there was any hope in my 
complaints leading to a change.  That's where D and Tango are different. 
  :-)

> Regarding D, Phobos, and Tango, I think the differences between the 
> Phobos and the Tango convention are small potatoes.  Import lines may 
> look a bit different, but /that's it/.  The only other difference in 
> style concerns global objects, of which Tango has perhaps 3-4, all of 
> which could be aliased to something else or wrapped in about ten 
> seconds.  How can such an issue possibly be enough to discuss so much, 
> let alone to use as grounds to reject a library entirely?  Frankly, if 
> this is the worst thing that people have to say about Tango then I think 
> the project has succeeded beyond my wildest expectations.

I agree with you there.  I find that as long as something is consistent, 
you can get used to it, and maybe even like it after you get past your 
initial revulsion.  But I don't actually find Tangos module naming 
disagreeable.  I'd prefer coarser granularity than one-file-one-class, 
but that can be fixed easily with a few public import modules.

I'm more interested in figuring what convention really makes the most 
sense for D overall.  Since what ever it is I'd like to follow it in my 
own libraries too.  I'm not sure what it is yet.  But it doesn't seem to 
me that just using what language X uses turns out so well.  C++ has a 
more flexible mapping of files to namespaces than D, so C++ conventions 
don't work so well.   Java with one-file-per-class and every file named 
after the class doesn't work so well with D where there are legitimate 
reasons to put two major classes in one file (or maybe no classes at 
all).  And there's also the redundancy issue with using the Java naming 
convention.

Here's an example from my porting of OpenMesh from C++ to D.  OpenMesh 
has a class OpenMesh::IO::Options defined in the file 
OpenMesh/Core/IO/Options.hh.  Trying to make as few changes as possible, 
I named the module OpenMesh.Core.IO.Options.  But it's been annoying me 
to no end because "Options" is such a generic name I never want to 
import that into my main namespace.  But I think that as an FQN it's a 
great name, except that the actual class is called ...IO.Options.Options.


--bb