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

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.

 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/
 -------------------------------------

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