www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tango - shallower hierarchy (was: Phango - questions)

reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
darrylb wrote:


  I still think 'tango.collection' versus 'tango.util.collection' is quite
  nitpicky.


Well, I was far, far from criticizing anything or/and anyone. I think Tango
is great library, very well organized with great effort put into details to
make library easy to use and very powerfull. And I will probably use it in
future...

I rather wanted to point out what I don't like in it. Of course I can live
with it as it is, but because it is still before v. 1.0 I think there is
sense in expressing my concerns? Maybe you will say that it is just a
matter of my personal taste, but when there is a lot of people who have
same taste isn't it better to make them all happy?

And that was my intent: to hear from others what they would like to change
in Tango packages. I was thinking here more about brainstorm-like
discussion not arguing what is better or worse and why.

My propositions:
1. tango.util.collection --> tango.collection
2. tango.util.time --> tango.time
3. tango.util.Convert --> tango.convert.Convert

Basically I don't understand why e.g. collection is kind of util? For
me "utility" is something more complex, and is similar in meaning to "tool"
(something which is produced using basic components). "Utilities" is also 
used in meaning of "the rest; other things", so IMHO its also not best
place for putting collection, time and conversion packages. All these
packages represents very basic concepts in every programming language, so
they probably deserve its own packages. (I am not native English speaker,
so please forgive me if I misinterpreted something here :-])

Best Regards
Marcin Kuszczak
(aarti_pl - www.zapytajmnie.com)
Nov 26 2007
next sibling parent darrylb <noemail example.com> writes:
Marcin Kuszczak Wrote:

 I rather wanted to point out what I don't like in it. Of course I can live
 with it as it is, but because it is still before v. 1.0 I think there is
 sense in expressing my concerns? Maybe you will say that it is just a
 matter of my personal taste, but when there is a lot of people who have
 same taste isn't it better to make them all happy?


Of course, and there's no problem expressing concerns. I was mostly replying to
whomever said they wanted it changed 'because it was less typing'. Suggesting a
change in location because it doesn't belong somewhere is somewhat different
than suggesting a change just so someone doesn't have to type so much. :). And
also, before anyone thinks any different, I don't have any more influence on
how the lib functions than any other tango user.


 My propositions:
 1. tango.util.collection --> tango.collection
 2. tango.util.time --> tango.time
 3. tango.util.Convert --> tango.convert.Convert


Suggesting such changes because you feel they are a more logical separation of
modules I have no issues with. I don't care if they are in
tango.util.timbuctu.collection as long as my code using them works :). Though
if it were up to me, I wouldn't want to clutter tango. with seemingly random
things, maybe tango.std?
Nov 26 2007
prev sibling next sibling parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Marcin Kuszczak wrote:


 My propositions:
 1. tango.util.collection --> tango.collection
 2. tango.util.time --> tango.time
 3. tango.util.Convert --> tango.convert.Convert
 
 Basically I don't understand why e.g. collection is kind of util? For
 me "utility" is something more complex, and is similar in meaning to
 "tool" (something which is produced using basic components). "Utilities"
 is also used in meaning of "the rest; other things", so IMHO its also not
 best place for putting collection, time and conversion packages. All these
 packages represents very basic concepts in every programming language, so
 they probably deserve its own packages. (I am not native English speaker,
 so please forgive me if I misinterpreted something here :-])
 
 Best Regards
 Marcin Kuszczak
 (aarti_pl - www.zapytajmnie.com)


Some more thoughts:

tango.core
- it seems to be another general aggregate type for different things like
tango.util. But I would expect modules should be very low level, commonly
used stuff (not complex as opposite to util). That said I wonder why there
is whole threading package in core? In what sense is threading 'core'? I
think that even on multicore machines it still be a lot of applications
which will be single threaded. What's more I found it counterintuitive:
when I want in my application threading support I would rather look for
tango.concurrency or tango.threading or tango.threads. In this package
should be also 'sync' package.

tango.io
- looks quite good for me. IO is coherent concept in tango, so that's why
there is so many different modules over there. But I would consider to
extract modules connected with files to another separate package.

tango.math
- looks ok.

tango.net
- putting cluster here I think is not best thing IMHO. Clustering seems to
be quite a different beast from http/ftp/smtp etc. Writing application for
http doesn't mean that I will need clusters. I understand that many
clusters just need network to work, but is it always true? I think that
there are cluster implementations which doesn't work in 'standard'
networks. I think that whole cluster package should be putted on main tango
level. BTW it will be good marketing for Tango - support for clusters in
standard library is really intriguing. What does mean tina in cluster
package? It is completely meaningless for newcomers - maybe some better
name would be more suitable?

tango.stdc
- ok

tango.sys
- ok

tango.text
- mostly ok; I would be happy to see all conversion modules in one package; 

tango.util
- comments in my previous post

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Nov 26 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Marcin Kuszczak wrote:

 
 Some more thoughts:
 
 tango.core
 - it seems to be another general aggregate type for different things like
 tango.util. But I would expect modules should be very low level, commonly
 used stuff (not complex as opposite to util). That said I wonder why there
 is whole threading package in core? In what sense is threading 'core'? I
 think that even on multicore machines it still be a lot of applications
 which will be single threaded. What's more I found it counterintuitive:
 when I want in my application threading support I would rather look for
 tango.concurrency or tango.threading or tango.threads. In this package
 should be also 'sync' package.


tango.core is roughly akin to java.lang in Java.  It is intended to 
contain essential type definitions, utilities, and expose runtime 
features.  Threading is actually a runtime feature, which is why it is 
in core.  tango.core.sync exists because I feel that simple threading 
primitives are an essential language feature.  Any additional threading 
utilities will likely go in tango.util.concurrent or the equivalent.


Sean
Nov 26 2007
next sibling parent reply Aarti_pl <aarti interia.pl> writes:
Sean Kelly pisze:

 Marcin Kuszczak wrote:

 Some more thoughts:

 tango.core
 - it seems to be another general aggregate type for different things like
 tango.util. But I would expect modules should be very low level, commonly
 used stuff (not complex as opposite to util). That said I wonder why 
 there
 is whole threading package in core? In what sense is threading 'core'? I
 think that even on multicore machines it still be a lot of applications
 which will be single threaded. What's more I found it counterintuitive:
 when I want in my application threading support I would rather look for
 tango.concurrency or tango.threading or tango.threads. In this package
 should be also 'sync' package.


 
 tango.core is roughly akin to java.lang in Java.  It is intended to 
 contain essential type definitions, utilities, and expose runtime 
 features.  Threading is actually a runtime feature, which is why it is 
 in core.  tango.core.sync exists because I feel that simple threading 
 primitives are an essential language feature.  Any additional threading 
 utilities will likely go in tango.util.concurrent or the equivalent.
 
 
 Sean


Now I understand. Thanks.

But still think that its not the best choice. Please notice that what 
you said is more implementor point of view than user point of view. If I 
want to use threads it's not important for me that its runtime feature. 
  I just want to make my job quickly without reading too much. Looking 
for threads in Tango and seeing only  main Tango hierarchy I have pretty 
good chance that I don't find it at first time. I can of course have 
"specific knowledge" and immediately go to tango.core. But necessity for 
"specific knowledge" is worse than relaying only on "general 
knowledge"/intuition, when creating libraries intended for wide audience.

It would be much better to put everything connected with threads into 
one package IMHO.

BR
Marcin Kuszczak
(aarti_pl)
Nov 27 2007
parent reply Sean Kelly <sean f4.ca> writes:
Aarti_pl wrote:

 Sean Kelly pisze:

 Marcin Kuszczak wrote:

 Some more thoughts:

 tango.core
 - it seems to be another general aggregate type for different things 
 like
 tango.util. But I would expect modules should be very low level, 
 commonly
 used stuff (not complex as opposite to util). That said I wonder why 
 there
 is whole threading package in core? In what sense is threading 'core'? I
 think that even on multicore machines it still be a lot of applications
 which will be single threaded. What's more I found it counterintuitive:
 when I want in my application threading support I would rather look for
 tango.concurrency or tango.threading or tango.threads. In this package
 should be also 'sync' package.


 tango.core is roughly akin to java.lang in Java.  It is intended to 
 contain essential type definitions, utilities, and expose runtime 
 features.  Threading is actually a runtime feature, which is why it is 
 in core.  tango.core.sync exists because I feel that simple threading 
 primitives are an essential language feature.  Any additional 
 threading utilities will likely go in tango.util.concurrent or the 
 equivalent.


 
 Now I understand. Thanks.
 
 But still think that its not the best choice. Please notice that what 
 you said is more implementor point of view than user point of view. If I 
 want to use threads it's not important for me that its runtime feature. 
  I just want to make my job quickly without reading too much. Looking 
 for threads in Tango and seeing only  main Tango hierarchy I have pretty 
 good chance that I don't find it at first time. I can of course have 
 "specific knowledge" and immediately go to tango.core. But necessity for 
 "specific knowledge" is worse than relaying only on "general 
 knowledge"/intuition, when creating libraries intended for wide audience.


How would you suggest things be arranged?  To me, the reasoning behind 
tango.core makes sense.  Array extends the functionality of a built-in 
type, so it belongs in core, Thread is essentially a language feature so 
it belongs in core, BitArray is a common and basic type, so is Variant, 
etc.  So I don't have any ideas for how to better separate things.

By the way, I know you may consider it an implementor point of view, but 
another reason for core being distinct was motivated by distribution 
concerns.  It is currently possible to ship and use a Tango library 
containing only core, stdc, and sys (the latter two for their C 
headers).  Spreading this functionality out would make for a more 
confusing core/runtime distribution if we ever decide to do so.  Such 
modularity was originally intended to be a selling point of the library, 
and I will admit to have been somewhat surprised that most people don't 
seem to care about it.


Sean
Nov 27 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Sean Kelly wrote:

 Such 
 modularity was originally intended to be a selling point of the library, 
 and I will admit to have been somewhat surprised that most people don't 
 seem to care about it.


More than likely the people that do care about it are simply happy you 
did it this way and so you hear no complaints.  <g>

Regan
Nov 27 2007
prev sibling next sibling parent reply Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:
Sean Kelly wrote:


 How would you suggest things be arranged?  To me, the reasoning behind
 tango.core makes sense.  Array extends the functionality of a built-in
 type, so it belongs in core, Thread is essentially a language feature so
 it belongs in core, BitArray is a common and basic type, so is Variant,
 etc.  So I don't have any ideas for how to better separate things.
 


I just and only say: please move concurrency support to separate package.
Everything else should stay where it is.


 By the way, I know you may consider it an implementor point of view, but
 another reason for core being distinct was motivated by distribution
 concerns.  It is currently possible to ship and use a Tango library
 containing only core, stdc, and sys (the latter two for their C
 headers).  Spreading this functionality out would make for a more
 confusing core/runtime distribution if we ever decide to do so.  Such
 modularity was originally intended to be a selling point of the library,
 and I will admit to have been somewhat surprised that most people don't
 seem to care about it.
 
 
 Sean



Your argumentation is based on false assumptions. I did not proposed to
spread or drop whole Core module. I just proposed to move threading into
separate package.

Why my proposition (as a whole) would be an advantage?
(http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=62424)

I think that it will be possible to more precisely define packages and that
way make it easier to find needed modules. Basically you will get:

tango.core
- simple modules, used relatively often in user code, spread in whole user
code, no close logical dependencies with other modules. Package for modules
which are logically too small to be putted into specific area package.

tango.<area> e.g. net, sys, math, io, concurrency, gui etc.
- packages for specific areas of programming. When you write program you
will probably need just a few of them. Modules in one area package are
logically interdependent between each other. Only loose dependencies
between area modules.

tango.util
- interdependant modules forming logical bigger entities, which can be
consider as tool or utility. It's more than packages in tango.<area> as
they creates bigger components, while tango.<area> packages don't have much
sense without other packages.

I think that such a structure is much more similar to way developer is
working on his program. When I write program and I need to make something
in background then I think: concurrency (not Core!), when I want to
transform one type into other I think: conversion (I even don't know what
to think now in current Tango state), when I write http server I think:
networking etc. etc. 

It will be much more like searching by Tag, not in hierarchy. Please notice
that this way seems to be much more intuitive for people than deep
hierarchies of logical connections (which are not always easy to
recognize). Examples?: collection of my photos in Digikam,
http://del.icio.us, google search, tags on web pages and a lot more. Anti
example? my internet bookmarks, which I am trying to put in hierarchy and
never have enough time for this. Last time I get to conclusion that
maintaining such a hierarchy is just more troubles than its worth. I almost
never use my bookmarks because its so much faster to write keyword in
Google...

I think that these are very fair arguments, and Tango people will take them
into consideration. My intent is not to start another flame war. I stated
clearly in my first post that I like Tango and plan to use it in future
anyway...

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Nov 27 2007
parent Yigal Chripun <yigal100 gmail.com> writes:
Marcin Kuszczak wrote:

 Sean Kelly wrote:
 

 How would you suggest things be arranged?  To me, the reasoning behind
 tango.core makes sense.  Array extends the functionality of a built-in
 type, so it belongs in core, Thread is essentially a language feature so
 it belongs in core, BitArray is a common and basic type, so is Variant,
 etc.  So I don't have any ideas for how to better separate things.


 
 I just and only say: please move concurrency support to separate package.
 Everything else should stay where it is.
 

 By the way, I know you may consider it an implementor point of view, but
 another reason for core being distinct was motivated by distribution
 concerns.  It is currently possible to ship and use a Tango library
 containing only core, stdc, and sys (the latter two for their C
 headers).  Spreading this functionality out would make for a more
 confusing core/runtime distribution if we ever decide to do so.  Such
 modularity was originally intended to be a selling point of the library,
 and I will admit to have been somewhat surprised that most people don't
 seem to care about it.


 Sean


 
 
 Your argumentation is based on false assumptions. I did not proposed to
 spread or drop whole Core module. I just proposed to move threading into
 separate package.
 
 Why my proposition (as a whole) would be an advantage?
 (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=62424)
 
 I think that it will be possible to more precisely define packages and that
 way make it easier to find needed modules. Basically you will get:
 
 tango.core
 - simple modules, used relatively often in user code, spread in whole user
 code, no close logical dependencies with other modules. Package for modules
 which are logically too small to be putted into specific area package.
 
 tango.<area> e.g. net, sys, math, io, concurrency, gui etc.
 - packages for specific areas of programming. When you write program you
 will probably need just a few of them. Modules in one area package are
 logically interdependent between each other. Only loose dependencies
 between area modules.
 
 tango.util
 - interdependant modules forming logical bigger entities, which can be
 consider as tool or utility. It's more than packages in tango.<area> as
 they creates bigger components, while tango.<area> packages don't have much
 sense without other packages.
 
 I think that such a structure is much more similar to way developer is
 working on his program. When I write program and I need to make something
 in background then I think: concurrency (not Core!), when I want to
 transform one type into other I think: conversion (I even don't know what
 to think now in current Tango state), when I write http server I think:
 networking etc. etc. 
 
 It will be much more like searching by Tag, not in hierarchy. Please notice
 that this way seems to be much more intuitive for people than deep
 hierarchies of logical connections (which are not always easy to
 recognize). Examples?: collection of my photos in Digikam,
 http://del.icio.us, google search, tags on web pages and a lot more. Anti
 example? my internet bookmarks, which I am trying to put in hierarchy and
 never have enough time for this. Last time I get to conclusion that
 maintaining such a hierarchy is just more troubles than its worth. I almost
 never use my bookmarks because its so much faster to write keyword in
 Google...
 
 I think that these are very fair arguments, and Tango people will take them
 into consideration. My intent is not to start another flame war. I stated
 clearly in my first post that I like Tango and plan to use it in future
 anyway...
 


I totally agree with this post (couldn't said it better myself).
Another benefit:
Sean Kelly mentioned that the current structure regarding the tango.core 
is due to the desire to make tango modular so that it'll be enough to 
just use core sys and stdc on smaller embedded systems.
With the above schema, you get that and you make the library even more 
modular in that you can create "profiles" for different use cases. you 
can choose which tango main packages are needed for each device. for 
example it probably won't make sense to have a GUI package on a text 
based device (maybe a blackberry is such an example).
on the other hand, it is required on a smart phone like an iphone. maybe 
even provide a different GUI package for mobile versus desktop applications.

you can see this approach for example at W3C. they define all their 
newer specifications with modules and profiles like XML, XHTML, CSS, etc..

Yigal
Nov 27 2007
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Sean Kelly wrote:
...

 
 By the way, I know you may consider it an implementor point of view, but 
 another reason for core being distinct was motivated by distribution 
 concerns.  It is currently possible to ship and use a Tango library 
 containing only core, stdc, and sys (the latter two for their C 
 headers).  Spreading this functionality out would make for a more 
 confusing core/runtime distribution if we ever decide to do so.  Such 
 modularity was originally intended to be a selling point of the library, 
 and I will admit to have been somewhat surprised that most people don't 
 seem to care about it.
 
 
 Sean


FWIW, I do like the modularity.

As evidenced by my other post, I am in the camp that thinks the 
module/package layout is mostly for the implementor's own use, and the 
users should use more appropriate search tactics that don't rely on some 
kind of a priori knowledge of Tango's terminology and structure.
Nov 27 2007
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Sean Kelly wrote:

 Marcin Kuszczak wrote:

 Some more thoughts:

 tango.core
 - it seems to be another general aggregate type for different things like
 tango.util. But I would expect modules should be very low level, commonly
 used stuff (not complex as opposite to util). That said I wonder why 
 there
 is whole threading package in core? In what sense is threading 'core'? I
 think that even on multicore machines it still be a lot of applications
 which will be single threaded. What's more I found it counterintuitive:
 when I want in my application threading support I would rather look for
 tango.concurrency or tango.threading or tango.threads. In this package
 should be also 'sync' package.


 
 tango.core is roughly akin to java.lang in Java.  It is intended to 
 contain essential type definitions, utilities, and expose runtime 
 features.  Threading is actually a runtime feature, which is why it is 
 in core.  tango.core.sync exists because I feel that simple threading 
 primitives are an essential language feature.  Any additional threading 
 utilities will likely go in tango.util.concurrent or the equivalent.


Can you give me a brief, 95% accurate guide to where to find the modules 
I want? Currently, I'm confused by the layout of Tango -- by why all the 
metaprogramming stuff, array manipulation functions, and Variant are in 
tango.core, for instance, and not tango.util; by why there are a bunch 
of stream iterators in tango.text; why tango.io contains hash streams 
and compression streams and all filesystem stuff except for a couple of 
path utility methods that are in tango.util.


 Sean
Nov 27 2007
prev sibling parent "Anders Bergh" <anders1 gmail.com> writes:
On Nov 27, 2007 2:50 AM, Marcin Kuszczak
<aarti_please_no spam_interia.pl> wrote:

 Some more thoughts:

 tango.core


I think this one is OK, as Sean explained in an earlier post about how
tango.core is like java.lang...

 tango.io
 - looks quite good for me. IO is coherent concept in tango, so that's why
 there is so many different modules over there. But I would consider to
 extract modules connected with files to another separate package.


Agreed.


 tango.math
 - looks ok.


Agreed.


 tango.net
 - putting cluster here I think is not best thing IMHO. Clustering seems to
 be quite a different beast from http/ftp/smtp etc. Writing application for
 http doesn't mean that I will need clusters. I understand that many
 clusters just need network to work, but is it always true? I think that
 there are cluster implementations which doesn't work in 'standard'
 networks. I think that whole cluster package should be putted on main tango
 level. BTW it will be good marketing for Tango - support for clusters in
 standard library is really intriguing. What does mean tina in cluster
 package? It is completely meaningless for newcomers - maybe some better
 name would be more suitable?


I agree completely - plus the cluster module hierarchy is really big...


 tango.stdc
 - ok


Agreed.


 tango.sys
 - ok


Agreed.


 tango.text
 - mostly ok; I would be happy to see all conversion modules in one package;


Yep, I agree with you here too...


 tango.util
 - comments in my previous post


Yeah.


 --
 Regards
 Marcin Kuszczak (Aarti_pl)
 -------------------------------------
 Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
 Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
 -------------------------------------


Anders
Nov 27 2007
prev sibling next sibling parent Matti Niemenmaa <see_signature for.real.address> writes:
Marcin Kuszczak wrote:

 My propositions:
 1. tango.util.collection --> tango.collection
 2. tango.util.time --> tango.time
 3. tango.util.Convert --> tango.convert.Convert


Not sure about the third one, but I agree with the first two, and would add:

4. tango.util.log --> tango.io.log

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Nov 26 2007
prev sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Marcin Kuszczak wrote:

 darrylb wrote:
 

  I still think 'tango.collection' versus 'tango.util.collection' is quite
  nitpicky.


 
 Well, I was far, far from criticizing anything or/and anyone. I think Tango
 is great library, very well organized with great effort put into details to
 make library easy to use and very powerfull. And I will probably use it in
 future...
 
 I rather wanted to point out what I don't like in it. Of course I can live
 with it as it is, but because it is still before v. 1.0 I think there is
 sense in expressing my concerns? Maybe you will say that it is just a
 matter of my personal taste, but when there is a lot of people who have
 same taste isn't it better to make them all happy?
 
 And that was my intent: to hear from others what they would like to change
 in Tango packages. I was thinking here more about brainstorm-like
 discussion not arguing what is better or worse and why.
 
 My propositions:
 1. tango.util.collection --> tango.collection
 2. tango.util.time --> tango.time
 3. tango.util.Convert --> tango.convert.Convert
 
 Basically I don't understand why e.g. collection is kind of util? For
 me "utility" is something more complex, and is similar in meaning to "tool"
 (something which is produced using basic components). "Utilities" is also 
 used in meaning of "the rest; other things", so IMHO its also not best
 place for putting collection, time and conversion packages. All these
 packages represents very basic concepts in every programming language, so
 they probably deserve its own packages. (I am not native English speaker,
 so please forgive me if I misinterpreted something here :-])
 
 Best Regards
 Marcin Kuszczak
 (aarti_pl - www.zapytajmnie.com)
 


I always get the feeling when using large libs that every hierarchy is 
flawed in bad ways.  EVERY hierarchy.

This makes me want to reexamine what I want out of the hierarchy. 
Typically I want to be able to find some functionality of the library in 
a quick fashion.
This leads me to believe that good search functionality in the docs is 
the key to accomplishing this.  It would be great to have some sort of 
powerful search engine for the docs.  Something that can see me type 
"templates" and know that I am really looking for "traits".
Nov 27 2007
parent "Kris" <foo bar.com> writes:
"Chad J" <gamerChad _spamIsBad_gmail.com> wrote ...
[snip]

 My propositions:
 1. tango.util.collection --> tango.collection
 2. tango.util.time --> tango.time
 3. tango.util.Convert --> tango.convert.Convert

 Basically I don't understand why e.g. collection is kind of util? For
 me "utility" is something more complex, and is similar in meaning to 
 "tool"
 (something which is produced using basic components). "Utilities" is also 
 used in meaning of "the rest; other things", so IMHO its also not best
 place for putting collection, time and conversion packages. All these
 packages represents very basic concepts in every programming language, so
 they probably deserve its own packages. (I am not native English speaker,
 so please forgive me if I misinterpreted something here :-])

 Best Regards
 Marcin Kuszczak
 (aarti_pl - www.zapytajmnie.com)


 I always get the feeling when using large libs that every hierarchy is 
 flawed in bad ways.  EVERY hierarchy.

 This makes me want to reexamine what I want out of the hierarchy. 
 Typically I want to be able to find some functionality of the library in a 
 quick fashion.
 This leads me to believe that good search functionality in the docs is the 
 key to accomplishing this.  It would be great to have some sort of 
 powerful search engine for the docs.  Something that can see me type 
 "templates" and know that I am really looking for "traits".



Couldn't agree more, Chad

This is partly what led to the Tango API web-page being a flat listing where 
you can immediately start typing to find something (with FF or whatever). 
Between the package names and the module names, you usually hit paydirt very 
quickly: http://dsource.org/projects/tango/docs/current/

We've also been playing around with a flat import hierarchy (as an 
experiment) where all the imports are in one package, but each import 
actually pulls in a few related things. The package name is tentatively 
called tango.group, so for example you might have import tango.group.text, 
or import tango.group.stream, or import tango.group.time.  You get the idea 
I'm sure - tango as a library is hierarchical, but you can always import it 
via a flat namespace too. Just an experiment that's been lingering for a 
while, but driven by what you describe above ... all hierarchies are flawed, 
depending on how you choose to look at them.

- Kris
Nov 27 2007