Tango Group Imports

[Georg Wrede]

>>Lars Ivar Igesund wrote:
>>
>>>In a response to community requests for fewer imports in Tango programs,
>>>especially for the smaller ones, we have created an experimental package
>>>called "group". This contains several modules, each publicly importing a
>>>themed collection of Tango modules. For example: tango.group.net and
>>>tango.group.stream.
>>
>>Well, I am not so sure that it is really what community wants. (BTW which
>>people are considered as Tango community? From D newsgroup? Tango users?
>>People from Tango IRC or Tango Web forums? People who doesn't use it now
>>by might use it in future?) Reading a few messages which have appeared on
>>D newsgroup and justifying your solution by myself I would rather say that
>>the problem is different and solutions solves other problem than
>>requested.
> 
> We are not sure either that tango.group is what the community wants
> (community here meaning D community, not necessarily Tango, although that
> may or may not be interchangeable), but note that requests from a single
> person wouldn't go in that category :) So this feature, in some form or
> another has been requested. Not because the hierarchy is deep, but because
> some think simple programs need too many imports. There is of course some
> necessity in such a feature having a short import paths.
> 
>>The problem, as I am seeing it, is that module paths are too long (deep
>>hierarchy). It causes some problems. Let me enumerate them once again:
>>
>>1. Lot to write in one import (quite trivial, but still problem)
>>
>>2. Difficult to remember where to find specific module. It should be
>>possible to find necessary module just using autocompletion feature in
>>IDE. Currently autocompletion doesn't help much, as hierarchies are deep
>>and it's necessary to remember path anyway.
>>
>>3. Sometimes modules are distributed in a quite illogical way. Or maybe it
>>would be better to say: not for everyone it is equally logical. The reason
>>is that nested package names are too loosly related with each other in
>>human mind (and especially in programmer mind). Example: net -- cluster;
>>util -- collection, core -- threading. Please try to find connection
>>between them in:
>>http://www.visuwords.com/fullsize.php
>>(I know that they are related, but this relation is quite weak, so it
>>gives impression that it is not logical).
> 
> Yes, I know you have these opinions, but compared to the group import
> feature, this is not something we consider a very highly requested thing to
> fix, and so we cannot say that there indeed _is_ a problem that needs
> fixing. Your points are sane of course, and you may in some respect be
> correct. If we were to change import hierarchy (I don't see how that is
> possible before 1.0 given our capacity), we would need to put _a lot_ of
> thought into it, to truly improve on the current situation, which I
> personally find quite good. For some packages, a solution similar to that
> of time may be appropriate, but we feel there is a limit to how many
> packages should be at the highest level too.
> 
> If you want such a process to start (be warned, it may not lead to
> anything), you need to write up a fairly complete proposal with the
> necessary reasoning and post it via a ticket.
> 
>>The problem which was solved by grouped imports is different. I can agree
>>that such a feature can be usefull, but only for people who uses some
>>specific group of modules very often in his/her code. When I would write
>>program which needs a lot of time calculations in almost every piece of my
>>code I would prefer to import whole time group at once, because it would
>>simplify my work without any costs. For example please show me a person
>>who uses in his/her code a lot of different kind of containers in almost
>>every module, so it would justify using "import tango.groups.collection"?
>>Usually you need two, three types of containers and that's enough.
>>In fact importing all types of containers, when you need just one or two I
>>would consider as a bad programmin practice. So this kind of group import
>>would be probably useless for people in most cases...
> 
> Still, many people want this :)
> 
>>At the end I want to say that I really miss newsgroup dedicated for
>>library development.

I agree with this paragraph.

As to the whole, I see that some "convenience imports" are welcome, 
possibly even with the majority of newcomers. (As in newcomers to D, not 
necessarily newcomers to the Concept of imports.)

A certain "convenience level" would ease the adoption of Tango, exactly 
as it would in Java or .NET. However, there's a fine line between actual 
raise of productivity and just confusing the public, or creating 
"crutches that let people skip learning how to walk". The extreme case 
being an "import-all 'feature'".)

IMHO, the main point would be to create (or actually refactor) the 
import hierarchy so that it is more /consistent, predictable, and 
intuitive/. This would ease the learning curve drastically (alas, only 
from step 2 forwards, but being a 10? step process, it would benefit the 
user at the end of the day).

Today, Phobos is like learning English. You have to learn by heart how 
to pronounce each and every single word. German, Finnish, and even 
French are entirely predictable: if you see a word in writing, you know 
how to pronounce it, and conversely, if you hear a word you immediately 
know how to spell it. (Yes, French is harder, but still.)

As I've understood, some of the motivation with Tango is to make it 
Predictable, meaning that you can get by with a certain amount of 
intuition or overall experience with libraries. This converts to 
massively reduced effort in getting fluent with the library.

Possible "convenience imports" should carefully consider these issues 
definitely deeper than just responding to "customer 'majority' demands". 
(PS, if Walter had said yes to all of our demands, by this time we'd all 
be using either plain C or Euphoria: don't give the audience what they 
demand, give them what they need!)