Any chance to call Tango as Extended Standard Library

[Aarti_pl]

Denis Koroskin pisze:
> On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith 
> <dlanguage at benjismith.net> wrote:
> 
>> IUnknown wrote:
>>> Agree. Which is why I said the problems you are facing seem to be 
>>> non-technical. I'm suggesting that the D library developers should 
>>> pick one and axe the other. *I* think what more important is to have 
>>> one single set of containers in a single style rather than have two 
>>> separate ones. There is going to be complaining for sure from the 
>>> current developers, but in my opinion, the target of having a single 
>>> standard library (with core and advanced modules to suit system/ app 
>>> programming) is more important than having to make a difficult choice.
>>
>> Totally agree. While I personally prefer the Java-style containers, 
>> I'd gladly accept the STL-style containers if it meant unification of 
>> Phobos and Tango.
>>
>> Having druntime is nice, sure, but application-level code and 
>> high-level libraries will bake the container API into their public 
>> interfaces, and any code that uses both the Phobos and Tango libraries 
>> would have to perform a zillion tedious conversions.
>>
>> In my mind, the things that need a unified API are (in order of 
>> importance):
>>
>> 1. GC and TypeInfo
>> 2. Data structures
>> 3. Algorithms
>> 4. String processing
>> 5. Date & Time
>> 6. IO
>>
>> Everything else (encryption, compression, sockets, regular 
>> expressions, could have a totally different API in Tango & Phobos and 
>> I wouldn't care much.
>>
>> Having a common runtime (GC and TypeInfo) is a neat trick, but pretty 
>> useless if the data structures and algorithms are entirely different.
>>
>> And, while I'm perfectly willing to accept either Java-style or 
>> STL-style containers, I'd also really appreciate it if the design 
>> anticipates and supports custom implementations (because I almost 
>> always end up implementing my own multimaps, multisets, circular 
>> queues etc)
>>
>> --benji
> 
> I think believe we could take advantage of current state of both 
> libraries in D2 - they are both incomplete and being redesigned to fit 
> D2 better.
> We could revisit both Tango and Phobos, and clean them up by removing 
> outdated modules and modules with same functionality. This will make 
> Phobos really small and much easier to learn.
> 
> On the other hand, Tango will continue providing all the extended 
> functionality.
> 
> Here is a list of Phobos modules that I believe could be safely removed:
> 
> - crc32 and std.md5 - these should be deprecated in favor of 
> tango.io.digest.Crc32 and tango.io.digest.Md5
> Tango is better designed and has support for other algoriths (MD2, MD4, 
> SHA256, SHA512, Tiger and more).
> See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto 
> for details.
> 
> - std.atomics - tango.core.Atomic is superior to it (std.atomics has 
> nothing but CAS anyway).
> - std.base64 - deprecate in favor of tango.io.encode.Base64
> - std.cover - is it supposed to be visible to user? Should it be in Phobos?
> - std.loader - deprecate in favor of tango.sys.SharedLib
> - std.bitarray
> - std.openrj
> - std.process - merge with tango.sys.Process
> - std.regexp - buggy, deprecate in favor of tango.text.Regex
> - std.socket, std.socketstream - deprecate in favor of tango.net.*
> - std.uni - deprecate in favor of tango.text.Unicode
> - std.uri - deprecate in favor of tango.net.Uri
> - std.xml - deprecate in favor of tango.text.xml.*
> - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
> 
> In almost *all* cases Tango has cleaner, faster and less buggy 
> implementation of the same functionality.
> 
> Other modules - does anyone use any of these:
> std.bitmanip
> std.bind
> std.boxer
> std.outbuffer
> std.stdint
> std.syserror
> std.system
> ?
> 
> There are a lot of modules that only exist in Phobos because of some 
> historical reasons or because Walter wrote it. Is it a sufficient reason 
> for them to stay?
> They are no doubt useful sometimes, but are we going to put everything 
> that is useful sometimes into Phobos?
> 
> I believe it would be better for everyone to keep Phobos simple and 
> prevent the two libraries from competing by separating the functionality.
> Once they don't compete anymore, users won't have to worry about what 
> library to use how to stay compatible.

Also my thoughts. Several months ago I send similar proposition to 
divide libraries responsibilities:
- for Phobos - low level API
- for Tango - higher level API

Stuff which is in both libraries should be designed together by both 
teams. Andrei is talking about new design for IO in Phobos. Why not to 
prepare this new design together with Tango people?

Some differences between philosophies of libraries should not stop 
merging. E.g. Phobos uses IO synchronized with C, but Tango is not. Why 
to divide libraries based on this? I think that there are cases where 
users would want one approach and also cases where they would want the 
other. IMHO standard library should have API allowing one or other 
approach depending on what user wants... So this difference is purely 
rhetorical...

BR
Marcin Kuszczak
(aarti_pl)
www.zapytajmnie.com - my christian site