"Jarrod" <qwerty@ytre.wq> wrote in message news:fnfa1t$1o1g$2@digitalmars.com...

> What bugs me overall is not the rift between features on either side, but rather the incompatibility issues. Unless there is a merge, there will be two standards..

Jarrod:

In what manner does Tangobos not provide the "merge" you describe?  It permits you to import, compile and link both phobos and Tango modules without fuss (which is what people had asked for). If you have a different idea of what that "merge" should instead be, would you please clarify?

On Sat, 26 Jan 2008 19:24:13 +0100, Lars Ivar Igesund wrote:

> Jarrod wrote:
> 
>> A merge could get the Tango team to work with Phobos too, so everyone can help it advance. Hey, it worked real well for compiz and beryl.
> 
> There are two aspects about Tango, the runtime and the user level API.
> 
> It would indeed be beneficial if the first could be compatible with the one in Phobos, and we still hope to achieve that in some sense.
> 
> As for the user API, that is what most people see, and what garners the most opinions. I don't think it will be particularly useful to merge that with Phobos, although they can be shipped together (as is done with the Tangobos bundles). Even though Phobos and Tango then can be used at the same time, that doesn't really make much sense unless you are forced that way by your library dependencies. If you use one part of Tango, you are likely to find good complimentary functionality elsewhere in Tango rather than in Phobos, and probably vice versa. As for working together, that is a possibility with the runtime, but considering we have rather different opinions on how to shape the library, it is very unlikely for user library, at least across the board. There are some minor parts that are fairly close to each other, and where fixes or improvements may be applied to both.

Okay I get it, Tango seems to have been made because some people didn't like the Phobos API, not because it lacked features. But in the end a lot of people choose Tango because of its features and better runtime. Not trying to rub a lemon in your eye here or anything and hey I could be very wrong on this, but maybe different API wasn't what most people needed?

Besides, if you merged couldn't you make a deal? Convince Walter to perhaps change or add a few API in Phobos to the 'better' Tango ones as you see them?


Oh and because I'm too lazy to reply to your other post directly :P Regarding toString: Yes Tango has toString but iirc you have to import each library for the datatype that you want to convert from, don't you? Not so good in template functions. All you need from Phobos is str.toString.

"Jarrod" <qwerty@ytre.wq> wrote in message news:fnge6e$1eto$1@digitalmars.com...
> On Sat, 26 Jan 2008 19:24:13 +0100, Lars Ivar Igesund wrote:
>
>> Jarrod wrote:
>>
>>> A merge could get the Tango team to work with Phobos too, so everyone can help it advance. Hey, it worked real well for compiz and beryl.
>>
>> There are two aspects about Tango, the runtime and the user level API.
>>
>> It would indeed be beneficial if the first could be compatible with the one in Phobos, and we still hope to achieve that in some sense.
>>
>> As for the user API, that is what most people see, and what garners the most opinions. I don't think it will be particularly useful to merge that with Phobos, although they can be shipped together (as is done with the Tangobos bundles). Even though Phobos and Tango then can be used at the same time, that doesn't really make much sense unless you are forced that way by your library dependencies. If you use one part of Tango, you are likely to find good complimentary functionality elsewhere in Tango rather than in Phobos, and probably vice versa. As for working together, that is a possibility with the runtime, but considering we have rather different opinions on how to shape the library, it is very unlikely for user library, at least across the board. There are some minor parts that are fairly close to each other, and where fixes or improvements may be applied to both.
>
> Okay I get it, Tango seems to have been made because some people didn't like the Phobos API, not because it lacked features. But in the end a lot of people choose Tango because of its features and better runtime. Not trying to rub a lemon in your eye here or anything and hey I could be very wrong on this, but maybe different API wasn't what most people needed?


There's a lot of history behind this, so it's understandable that many newer folks won't know the story. You might take a look at the Ares forum on dsource to get a broader picture, but it boils down to one fact: phobos was going nowhere - patches were being sent to walter and not being applied for over a year, etc. Not to mention that it was, at the time most would agree, a bit of a design mish-mash. A variety of folks felt that Walter should not be burdened with the library, when it was abundantly clear his focus and priority was the language instead.

The upshot was something "owned", guided, driven and maintained by the community instead. To suggest that was borne of merely a dislike for an API is like saying D exists simply because Walter doesn't like Bjarne's haircut.


> Besides, if you merged couldn't you make a deal? Convince Walter to perhaps change or add a few API in Phobos to the 'better' Tango ones as you see them?
>
>
> Oh and because I'm too lazy to reply to your other post directly :P Regarding toString: Yes Tango has toString but iirc you have to import each library for the datatype that you want to convert from, don't you? Not so good in template functions. All you need from Phobos is str.toString.


Where phobos is monolithic, Tango is modular. There's a price to pay for that, in that modularity can sometimes require an extra import. While this is hardly an impediment, you could happily import tango.util.Convert instead, and exchange modularity for triviality. This is a general philosophy within Tango - keep things modular, and provide a wrapper on top for those who prefer that instead. It's more work to design and build a library that way (often much more), but it's worth it to many folks.