Bill Baxter wrote:
> Lars Ivar Igesund wrote:
> 
>> Dear D community
>>
>> The first public release of Tango is now ready for download.
> 
> 
> Can you folks comment on what you see as the the transition plan?  The migration document does a decent job explaining how to convert from Phobos over to Tango whole hog, but realistically not everyone can make this transition overnight.  So anyone writing libraries intended for consumption by 3rd parties is faced with the options of
> A) Port whole hog -- abandoning any users who are stuck with Phobos
> B) Don't port at all -- annoying any users hoping to move to Tango
> C) Port while maintaining compatibility -- annoying the poor me who has to deal with incompatibilities in the most basic functions (e.g. toString, writefln)
> 
> 
> Option C) seems like the most logical.  And given that, it seems like a compatibility library would be helpful.  Some way to make it easier to write code that looks mostly like Tango code with a minimum of version statements, but which actually calls on Phobos at the bottom layers.
> 
> Or maybe I've misunderstood the options.  Given the new GC and new Object class it seems like any use of Tango with Phobos is radioactive and fraught with peril, but maybe its not so bad?  For example, can one use the io framework from Tango while still using Phobos as the std lib?
> 
> Anyway, I think a page on how to migrate from Phobos to Tango while mainintaining backwards compatibility would be of great use to library writers.
> 
> --bb

I and several others are trying to garner an effort to essentially port Phobos to Tango in such a way that most Phobos software could be compiled verbatim. This is the best option in my opinion, because it provides full backwards compatibility.

 - Gregor Richards

Bill Baxter wrote:
> Lars Ivar Igesund wrote:
>> Dear D community
>>
>> The first public release of Tango is now ready for download.
> 
> Can you folks comment on what you see as the the transition plan?  The migration document does a decent job explaining how to convert from Phobos over to Tango whole hog, but realistically not everyone can make this transition overnight.  So anyone writing libraries intended for consumption by 3rd parties is faced with the options of
> A) Port whole hog -- abandoning any users who are stuck with Phobos
> B) Don't port at all -- annoying any users hoping to move to Tango
> C) Port while maintaining compatibility -- annoying the poor me who has to deal with incompatibilities in the most basic functions (e.g. toString, writefln)

I don't know that this is entirely fair--you paint the existence of Tango as annoying in three entirely different ways :-).  That said, code compatibility issues are (hopefully) not a long-term problem as people will either port their code or they won't.  What worries me personally about presenting option C as an official alternative is that it places us (ie. the Tango team) in a position of supporting a Phobos facade for a potentially indefinite period.

> Option C) seems like the most logical.  And given that, it seems like a compatibility library would be helpful.  Some way to make it easier to write code that looks mostly like Tango code with a minimum of version statements, but which actually calls on Phobos at the bottom layers.

I think it would be more the reverse.  A library that looks like Phobos but calls Tango at the bottom layers.  But it's still a lot of code to maintain that has no direct relation to the project.  Perhaps such a thing could be created and managed separately?


Sean

Bill Baxter wrote:

> C) Port while maintaining compatibility -- annoying the poor me who has to deal with incompatibilities in the most basic functions (e.g. toString, writefln)

I too wonder why those were changed. Why not leave them be? What's so terrible about toString? It returns a string, doesn't it? Furthermore, there's no toUTF16, toUTF32, so what's the point?

Seems like a change for the sake of being different.

L.

Lionello Lunesu wrote:
> Bill Baxter wrote:
> 
>> C) Port while maintaining compatibility -- annoying the poor me who has to deal with incompatibilities in the most basic functions (e.g. toString, writefln)
> 
> 
> I too wonder why those were changed. Why not leave them be? What's so terrible about toString? It returns a string, doesn't it? Furthermore, there's no toUTF16, toUTF32, so what's the point?
> 
> Seems like a change for the sake of being different.
> 
> L.

Well, that's not entirely fair :)

You mention two specific areas:

1) writefln does not support the functionality we needed. It has no support for either Locales, or for indexing the arguments themselves (both for supporting I18N). We decided to go a different route, because we beleive I18N is important enough to warrant some direct attention. (locale is not quite fully enabled in this release, but it will be in the next one).

It would be cool if you ported the writefln code though, as an external option -- we can't expect I18N support to be to everyone's liking.


2) there's no toUtf16() and toUtf32()? This is not the case. Tango uses those in a number of modules to do just what they indicate. There are modules that expose all three ... in certain cases they're also templated for the base type that you want stored within (e.g. store as dchar, expose as all three types).

This really was a not an easy decision for us to take, as I'm sure you can imagine.

Tango is what it is, and yet is open to change too. There's a /lot/ of people involved as you can see on the site, and I do hope you'll give it a good look?

Lionello Lunesu wrote:

> Bill Baxter wrote:
> 
>> C) Port while maintaining compatibility -- annoying the poor me who has to deal with incompatibilities in the most basic functions (e.g. toString, writefln)
> 
> I too wonder why those were changed. Why not leave them be? What's so terrible about toString? It returns a string, doesn't it? Furthermore, there's no toUTF16, toUTF32, so what's the point?
> 
> Seems like a change for the sake of being different.
> 
> L.

This has been argued before on these newsgroups. It is a change for the sake of consistency and correctness, nothing else, and Walter stated that this would be a better solution, except that he finds the symbol ugly (!). Tango does have a String class and I believe it would be misleading to return d/w/char[] from toString in that case.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango

Gregor Richards wrote:

> Bill Baxter wrote:
>> Lars Ivar Igesund wrote:
>> 
>>> Dear D community
>>>
>>> The first public release of Tango is now ready for download.
>> 
>> 
>> Can you folks comment on what you see as the the transition plan?  The
>> migration document does a decent job explaining how to convert from
>> Phobos over to Tango whole hog, but realistically not everyone can make
>> this transition overnight.  So anyone writing libraries intended for
>> consumption by 3rd parties is faced with the options of
>> A) Port whole hog -- abandoning any users who are stuck with Phobos
>> B) Don't port at all -- annoying any users hoping to move to Tango
>> C) Port while maintaining compatibility -- annoying the poor me who has
>> to deal with incompatibilities in the most basic functions (e.g.
>> toString, writefln)
>> 
>> 
>> Option C) seems like the most logical.  And given that, it seems like a compatibility library would be helpful.  Some way to make it easier to write code that looks mostly like Tango code with a minimum of version statements, but which actually calls on Phobos at the bottom layers.
>> 
>> Or maybe I've misunderstood the options.  Given the new GC and new Object class it seems like any use of Tango with Phobos is radioactive and fraught with peril, but maybe its not so bad?  For example, can one use the io framework from Tango while still using Phobos as the std lib?
>> 
>> Anyway, I think a page on how to migrate from Phobos to Tango while mainintaining backwards compatibility would be of great use to library writers.
>> 
>> --bb
> 
> I and several others are trying to garner an effort to essentially port Phobos to Tango in such a way that most Phobos software could be compiled verbatim. This is the best option in my opinion, because it provides full backwards compatibility.
> 
>   - Gregor Richards

There already is the tango.phobos project at DSource which contains a "port" of Phobos, although unsupported by the Tango team.

It has changed all std. to phobos. and been made to work with the Tango runtime. There are a couple of catches with this version. Firstly, threading is tightly integrated with the GC and as such the Tango threading should be used, secondly it has afaik only (or mostly) been tested on Linux and with DMD.

What is there should be up-to-date with DMD 1.004, but no guarantees. Anyone who wants to get involved are free to do so :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango

Good work guys! Keep going! :)

Even though I like Tango project, I would never abandon Phobos, because I like Phobos simplicity (ie. it is not "too much OO"). As we discussed this many times on IRC, many other people think this way.
Whenever I come to something I do not like in Phobos, I would either post some suggestion to Phobos maintainer, or develop my own module which adds needed functionality.
Tango is realy a GOOD and HUGE work, and as someone said previously - if You realy want Tango as replacement for Phobos, You need to have all Phobos functionality (ie. backward-compatibility), so Phobos users could use Tango out-of-box.

Kind regards

Dejan

Awesome library. My compliments especially to the documentation writers,  the little I have read before dsource couldn't handle the traffic anymore was of exceptional quality. I hope the docs can be read offline too in the near future.

Lutger wrote:
> Awesome library. My compliments especially to the documentation writers,  the little I have read before dsource couldn't handle the traffic anymore was of exceptional quality. I hope the docs can be read offline too in the near future.

I'm certain they'll be very happy to hear that! Dsource is back too <g>

Offline docs is something that's been discussed, yet not really been pushed as a priority. Good that you bring it up

kris wrote:
> Offline docs is something that's been discussed, yet not really been pushed as a priority. Good that you bring it up

Just a zip of the api reference would be most helpful for quick browsing, and in the case of absent internet or dsource connection.