Tango - shallower hierarchy (was: Phango - questions)

[Yigal Chripun]

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