Any chance to call Tango as Extended Standard Library
Jason House
jason.james.house at gmail.com
Fri Jan 23 05:29:41 PST 2009
Denis Koroskin Wrote:
> On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house at gmail.com> wrote:
>
> > Denis Koroskin Wrote:
> >
> >> 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.
> >
> > That's an interesting list. Without the ability to distribute Phobos
> > and Tango together from the digitalmars.com site, I doubt anything will
> > get dropped from Phobos in favor of what is in Tango. For a combined
> > distribution to ever occur requires a whole lot more coordination
> > between Phobos and Tango that I doubt we'll see for a very long time.
> >
>
> Is there any problem? Walter gave a special permission to Tango team to distribute DMD with Tango. I believe Tango team can give similar permission to distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I don't see why it can't ship with DMD. Unless Walter is against it.
If after all the pledges to fix the Tango/Phobos split and a lot of time to take action, eveything should be fixed. When we have to say "can" "could" or other hypothetical terms, it makes me think there is a problem.
I am disapponted that druntime can't make its way into D1. Without that, nothing will happen with D1, ever. Meanwhile D2 is at least on hold. Lately, there's been discussion of how the licenses of Phobos and Tango are different. I assume that any legal ambiguity will block distribution by digital mars
> Oh, and Tango2 should exists, of course.
>
> >
> >
> >> Other modules - does anyone use any of these:
> >> std.bitmanip
> >> std.bind
> >> std.boxer
> >> std.outbuffer
> >> std.stdint
> >> std.syserror
> >> std.system
> >> ?
> >
> > std.bind is useful for binding data that will change before the delegate
> > is called. I've used bind a lot when doing inter-thread communication
> > with queues of pending commands.
> >
> > I'd also like to use a variant of bit array with fixed sizes, easier
> > initialiation, and uses the SSE instruction set. Right now, neither
> > Phobos nor Tango contains what I want.
>
>
>
More information about the Digitalmars-d
mailing list