www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Tango Group Imports

reply Lars Ivar Igesund <larsivar igesund.net> writes:
Dear D community, 

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. 

These are now in Tango SVN trunk, and will be part of the next release.
Considering they are an experimental feature, we will look to your feedback
before deciding their fate.

The Tango homepage can be found at http://www.dsource.org/projects/tango

Contact:
http://www.dsource.org/projects/tango/wiki/Contact

Signed,

The Tango Team

http://www.dsource.org/projects/tango/wiki/Contributors

----

Tango is a D library providing a cohesive runtime and library for the D
programming language. A feature list can be found on
http://www.dsource.org/projects/tango/wiki/Features
Dec 20 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Lars Ivar Igesund wrote:
 Dear D community, 
 
 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. 
Like the idea, not so wild about the name. How about "api"? To use the collections API you say tango.api.collection. Or focus on the simplicity: tango.simple.* tango.flat.* tango.direct.* tango.easy.* tango.ez.* // short to type! Or even 'use'/'using' might be slick: tango.use.collection; tango.using.collection; Or 'lib': import tango.lib.collection; Or thinking of shortest possible words (because it's for convenience to begin with): tango.go.collection tango.by.collection tango.hi.collection // as in hello collections! tango.my.collection tango.of.collection tango.ye.collection // for that olde worlde feel! tango.on.collection tango.to.collection // dance on over to the collection department tango.up.collection tango.ez.collection Or go with the "tango" theme and use a spanish word: tango.el.collection tango.la.collection tango.dela.collection tango.del.collection tango.del.tacos Or maybe a less generic word than "group": tango.suite.collection tango.pkg.collection But after all that, I like "api" best, because it's short and seems to describe well what it does. You want to use the collections api with no fuss? then tango.api.collection is for you! --bb
Dec 21 2007
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:
 Lars Ivar Igesund wrote:
 Dear D community,
 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. 
Like the idea, not so wild about the name. How about "api"? To use the collections API you say tango.api.collection. Or focus on the simplicity: tango.simple.* tango.flat.* tango.direct.* tango.easy.* tango.ez.* // short to type! Or even 'use'/'using' might be slick: tango.use.collection; tango.using.collection; Or 'lib': import tango.lib.collection; Or thinking of shortest possible words (because it's for convenience to begin with): tango.go.collection tango.by.collection tango.hi.collection // as in hello collections! tango.my.collection tango.of.collection tango.ye.collection // for that olde worlde feel! tango.on.collection tango.to.collection // dance on over to the collection department tango.up.collection tango.ez.collection Or go with the "tango" theme and use a spanish word: tango.el.collection tango.la.collection tango.dela.collection tango.del.collection tango.del.tacos Or maybe a less generic word than "group": tango.suite.collection tango.pkg.collection But after all that, I like "api" best, because it's short and seems to describe well what it does. You want to use the collections api with no fuss? then tango.api.collection is for you! --bb
Same here. I'm not so excited about "group" for some reason. "use" or "using" is an unusual idea, but strangely attractive. It goes against the grain by using a participle in a package naming scheme... but it could be an good way to differentiate the flat scheme from the standard tango namespace. Also liked your suggestions of "suite" and "lib". -JJR
Dec 21 2007
parent reply bobef <bobef nospam_abv.bg> writes:
Any why not just tango.http.all or tango.all.http instead of fancy stuff?
Dec 22 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
bobef wrote:
 Any why not just tango.http.all or tango.all.http instead of fancy stuff?
As for the former: I was assuming they want to have the convenience layer in its own package so people who aren't interested can just ignore the whole package. Or perhaps it's more so you can get a quick overview of the convenience modules at-a-glance without having to run a filesystem search for all files matching *.all. Or maybe it's that the idea is for the names to be as short as possible. In the http case you give, I think that would actually have to be tango.net.http.all, no? As for the latter: It may be confusing to use "all" as a package like that since it's commonly used the other way. But that seems a weak argument. Actually tango.all.net looks pretty good to me. --bb
Dec 22 2007
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 Like the idea, not so wild about the name.
A lot of ideas were tossed around in IRC. In the end, group seemed to be the best fit, as you were "grouping" related packages together. In any case, it doesn't matter too much what the name is :) As long as it's a name that's abstract enough not to be desirable for another package name. -Steve
Dec 27 2007
prev sibling parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Lars Ivar Igesund wrote:

 Dear D community,
 
 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. 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). 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... Anyway I am happy that at least time package found its way out from util into root :-) (Reference: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=62424 )
 These are now in Tango SVN trunk, and will be part of the next release.
 Considering they are an experimental feature, we will look to your
 feedback before deciding their fate.
At the end I want to say that I really miss newsgroup dedicated for library development. I know that Tango people prefer IRC and Web Forums, but I have to say that this channels of communications are very inconvenient for me. I usually have only a little time in the evening to read/write something so newsgroup is very convenient. It doesn't need from me my immediate answer (like IRC), and allows me to use convenient environment (my environment - not the one which somebody decided is good for me - I mean web interface). So I definitely vote to open newsgroup: digitalmars.D.library (ping: Walter) -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Dec 22 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Marcin Kuszczak wrote:

 Lars Ivar Igesund wrote:
 
 Dear D community,
 
 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 know that Tango people prefer IRC and Web Forums,
 but I have to say that this channels of communications are very
 inconvenient for me. I usually have only a little time in the evening to
 read/write something so newsgroup is very convenient. It doesn't need from
 me my immediate answer (like IRC), and allows me to use convenient
 environment (my environment - not the one which somebody decided is good
 for me - I mean web interface).
Unless one could truly integrate Trac with a dedicated Tango newsgroup (something like bugzilla and D.bugs), we feel that NGs lacks too much trackability for incoming requests and the surrounding discussions. IRC is convenient for the cases where some real time talk is preferable to close cases that seems to stay too long in the pipeline in other fora. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 23 2007
next sibling parent Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Lars Ivar Igesund wrote:
 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 :) 
Oh, well... There were at least two other people who expressed their concerns about long imports on D newsgroup... Also whole Phango thread seemed to be about stylistic differences between Phobos and Tango. And 'Phobos way' supporters were quite vocal :-) Seeing a lot of different proposals, I think that my proposition is not very radical. That's just (mostly) minor adjustments which IMHO would help to make Tango friendlier for Phobos/C++ users. BTW I think that in area of stylistic issues the best tool to measure demand are pools. Stylistic issues are usually very hard to justify by only rational arguments. In these cases "point of view" is usually more important than rationale. So here pools are perfect tool to get information what is better. Maybe it wouldn't be so difficult to integrate into Tango web page some poolling support?
 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.
 
I will put it on Tango ticket system in hope that it would be considered by Tango developers :-) Anyway thanks for very impressive work on Tango! -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Dec 30 2007
prev sibling parent Georg Wrede <georg nospam.org> writes:
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!)
Dec 30 2007