Phango - questions

[Bill Baxter]

Sean Kelly wrote:

> However, this aim towards customizability does increase the learning 
> curve associated with Tango.  Often it is not obvious just what to 
> import to perform simple operations, and it is often necessary to import 
> quite a few modules for an average task.  Also, some users find the lack 
> of convenience functions somewhat daunting.  These are all areas where 
> we are trying to improve Tango, but I personally feel that such an 
> effort can only ever be moderately successful.  This is because, as I 
> said earlier, every application has slightly different requirements, and 
> such convenience functions must necessarily assume a specific set of 
> requirements.  So I would expect such functions to be most useful to a 
> novice programmer and for one-off projects rather than for 
> industrial-grade applications.
> 
> Sorry for being so long winded, but this is the basic rationale behind 
> Tango's current design.  Given this, I think our greatest challenge is 
> probably making the library more accessible to new users.  If you or 
> anyone else has suggestions for this or anything else, then please let 
> us know either here or in the Tango forums.  I deal almost exclusively 
> with rather obscure parts of the library, so I tend to forget about the 
> high-level issues people face with Tango.

> I'll admit that the double name "Options.Options" thing drives me crazy 
> sometimes.  But I haven't come up with any language feature to improve 
> on that.  So far, I just use selective imports, aliasing, etc, to make 
> my code more compact.

Asking for a feature where class package.Options.Options can be accessed 
as just package.Options seems a decent idea at first -- the same trick 
works for templates after all -- but I don't think it would pan out. 
Other than that I don't see any other obvious language-level changes 
that would fix it.  So maybe we're stuck with Options.Options.

One thing that might help make long package names seem less annoying 
generally would be aliases for packages, or a package "with".

    alias tango.util.collection TUC;
    import TUC.ArrayBag;
    import TUC.LinkSeq;

Or

    with (tango.util.collection) {
       import ArrayBag;
       import LinkSeq;
    }

Or
    import tango.util.collection : ArrayBag, LinkSeq


Given that you _can_ have "Net.d" and "net/" in the same directory, 
thanks to Tango's naming convention, maybe tango could provide some 
coarser granularity imports via up-cased directory names.  So "import 
tango.Net" would give you all the commonly needed net stuff.   "import 
tango.net.Cluster" would give you the important stuff from cluster/*.d

I guess it's not so different from the "all.d"  But I think it has more 
legs than all.d.  With all.d you're pretty much promising that it's 
going to have everything, and it better be everything or people will be 
confused why "import tango.net.all" doesn't really import *everything* 
from tango.net.  If you need variations, you're stuck.  And making a 
convention of other "all"-like modules gets you into a wierd area of 
violating your own style conventions whereby modules should be 
uppercase.   Whereas you could easily have variations with what I'm 
suggesting: "import tango.Net" -- all major tango.net stuff, "import 
tango.NetBase" just the fundamental net stuff without all the subdirs.

Just an idea.  Not sure how much I like it not having used Tango much.

--bb