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