Bill Baxter wrote:

> Sean Kelly wrote:
>> Bill Baxter wrote:
>>> Lars Ivar Igesund wrote:
>>>> Frits van Bommel wrote:
>>>>
>>>>> Which one to use is hard to say at this point. I've been trying out
>>>>> Tango since its release and I like it but I sometimes miss some
>>>>> parts of
>>>>> Phobos. Whether this is because Phobos is just more familiar to me or
>>>>> actually better is hard to say...
>>>>
>>>> Note that what you miss that you feel you have in Phobos, is very
>>>> much part
>>>> of the feedback we would like.
>>>
>>> I'm having trouble understanding first why Tango had to be made mutually exclusive to Phobos (is it just changes to object.d? were those really necessary?)
>> 
>> The Tango runtime code contains quite a few differences compared to Phobos, but the bulk of these are hidden from the user.  Some of the more visible differences are that Error has been dropped, Exception reworked, Object.toString() changed to Object.toUtf8(), and the Thread object has a slightly different interface.  During development, both in Ares/Mango and now in Tango, no effort was made to either deliberately mimic or to differ from Phobos.  Rather, a design was chosen that simply made the most sense.  That said, a great deal of effort has been made to avoid changing anything that feels like a language feature, and it was sometimes difficult to determine where the line should be drawn.  The Object.toString() issue sits pretty squarely on that line, and a great deal of discussion took place before that particular change was agreed upon.
>> 
>>  > and if object.d differences are the only reason, then I
>>> still don't really get why most Phobos code can't still be imported as is or with trivial changes.  For example, phobos' std.path doesn't seem to have any direct dependencies on the gc API or on a particular version of object.d.  What's the issue?
>> 
>> Most Phobos code can be imported as is or with trivial changes, it's simply a matter of taking the time to do so.  Frank actually did this a while back for his own use, and the project now lives on dsource as tango.phobos.  I am sure it could do with some dedicated maintainers -- developing one library is quite enough for me :-)
> 
> Ok.  Thanks for the explanation.
> There were some comments before about "porting phobos to tango" that
> just made it sound like a bigger job that it apparently is in fact.

I believe someone mentioned implementing the phobos API using Tango.

> 
> As many people have noticed, phobos doesn't really change very quickly <g> so I suspect it wouldn't be too much work to maintain compatibility once achieved.  Patches seem like a good way to go.  If you have a patch against phobos then applying it to new versions of phobos would likely just work, since the changes to phobos are few.
> 
> --bb

If someone wants to help mantaining the tango.phobos project, they are welcome to do so. The project both has a Trac environment and a forum in phpBB.

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

Lars Ivar Igesund wrote:
> 
> If someone wants to help mantaining the tango.phobos project, they are
> welcome to do so. The project both has a Trac environment and a forum in
> phpBB.
>

How can I find the trac environment? It is not listed under dsource/projects.

Lutger wrote:

> Lars Ivar Igesund wrote:
>> 
>> If someone wants to help mantaining the tango.phobos project, they are welcome to do so. The project both has a Trac environment and a forum in phpBB.
>>
> 
> How can I find the trac environment? It is not listed under dsource/projects.

The adress is

http://www.dsource.org/projects/tango.phobos

I believe all project tracs can be found be exchanging the name part of the link.

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

"Lars Ivar Igesund" <larsivar@igesund.net> schrieb im Newsbeitrag news:eqdcp0$r0s$1@digitaldaemon.com...
> Frits van Bommel wrote:
>
>> Which one to use is hard to say at this point. I've been trying out Tango since its release and I like it but I sometimes miss some parts of Phobos. Whether this is because Phobos is just more familiar to me or actually better is hard to say...
>
> Note that what you miss that you feel you have in Phobos, is very much
> part
> of the feedback we would like.

I prefer the string function of phobos over the one provided by Tango.
A D implementation of the Python string functions (with the same names) I
would find great.

- Ralf

Ralf Schneider wrote:
> "Lars Ivar Igesund" <larsivar@igesund.net> schrieb im Newsbeitrag news:eqdcp0$r0s$1@digitaldaemon.com...
>> Frits van Bommel wrote:
>>
>>> Which one to use is hard to say at this point. I've been trying out
>>> Tango since its release and I like it but I sometimes miss some parts of
>>> Phobos. Whether this is because Phobos is just more familiar to me or
>>> actually better is hard to say...
>> Note that what you miss that you feel you have in Phobos, is very much part
>> of the feedback we would like.
> 
> I prefer the string function of phobos over the one provided by Tango.
> A D implementation of the Python string functions (with the same names) I would find great.

Have you looked at tango.text.Util?  Naming aside (some names are being changed IIRC), is there functionality you feel is mising, etc?


Sean

Lars Ivar Igesund wrote:
> Frits van Bommel wrote:
> 
>> Which one to use is hard to say at this point. I've been trying out
>> Tango since its release and I like it but I sometimes miss some parts of
>> Phobos. Whether this is because Phobos is just more familiar to me or
>> actually better is hard to say...
> 
> Note that what you miss that you feel you have in Phobos, is very much part
> of the feedback we would like.
> 

Okay -- I'm really sorry if any of this seems to have a negative tone. I hesitate to write this since I have a lot of respect for the Tango design in general, but there are a couple of friction points I've noticed.

1. writefln / format replacements

Concerning standard output and string formatting, in phobos I can do these operations:

  writefln("%s %s %s", a, b, c);
  format("%s %s %s", a, b, c);

How do I do these in Tango?  The change to "{0} {1}" stuff is fine with me, in fact I like it, but this syntax:

  Stdout.formatln("{0} {1} {2}", a, b, c);
  Format!(char).convert("{0} {1} {2}", a, b, c);

Is awkward.  And these statements are used *all the time*.  In a recent toy project I wrote, I used Stdout 15 times, compared to using "foreach" only 8 times.  I also use the "format to string" idiom a lot (oddly enough, not in that project), and it's even more awkward.

That's why I think phobos really did the "Right Thing" by keeping those down to one token.  Second, the fact that the second one does exactly what the first does but you need to build a template, etc, is annoying.  I kept asking myself if I was doing the right thing because it seemed like I was using too much syntax for this kind of operation (I'm still not sure it's the best way to go -- is it?)

I know about Cout as a replacement for the first one, but as far as I can tell it doesn't take parameters, and usually I need some.

When people ask "why D", I tell them that simpler syntax, better defaults and better garbage collection, each gain us a 50 % reduction in code, and when all three apply to a problem, D can each C++'s lunch. Let's not throw away the simpler syntax.

(I'm not talking about architecture changes, just wrappers with standardized short names that can become familiar to all D users.)


2. toString and toUtf8 (collisions)

The change of the terminology is actually okay with me.

But phobos has a way of using toString as both a method and a top-level function name, all over the place.  This gets really clumsy because you can never use the top level function names when writing a class unless you fully qualify them.

For example, std.cpuid.toString(), always has to be fully qualified when called from a class, and seems nondescriptive anyway.  All the std.conv.toString() functions are nice but it's easy to accidentally call the in-class toString() by accident.

For the utf8 <--> utf16 and similar, it's frustrating to have to do this:

dchar[] x32 = ...;
char[] x8 = tango.text.convert.Utf.toUtf8(x32);

But you have to fully qualify if you are writing code in any class or struct.  If these were given another name, like makeUtf8, then these collisions would not happen.

Actually, if it wasn't already out there, I would want to go through all of phobos and remove all the common collisions.  They are much less trouble in an "import" system than in an "include" system, but every time there is a collision it requires an additional "edit-compile" cycle, and/or a fully qualified name.

And if you forget to import all the right modules, its can impact the correctness angle, because you pick up someone else's "toString" from who knows where.

I'm just saying, ideally tango should not be duplicating this with toUtf8 etc.

Kevin

Kevin Bealer wrote:

> Lars Ivar Igesund wrote:
>> Frits van Bommel wrote:
>> 
>>> Which one to use is hard to say at this point. I've been trying out Tango since its release and I like it but I sometimes miss some parts of Phobos. Whether this is because Phobos is just more familiar to me or actually better is hard to say...
>> 
>> Note that what you miss that you feel you have in Phobos, is very much part of the feedback we would like.
>> 
> 
> Okay -- I'm really sorry if any of this seems to have a negative tone.
> I hesitate to write this since I have a lot of respect for the Tango
> design in general, but there are a couple of friction points I've noticed.
> 
> 1. writefln / format replacements
> 
> Concerning standard output and string formatting, in phobos I can do these operations:
> 
>    writefln("%s %s %s", a, b, c);
>    format("%s %s %s", a, b, c);
> 
> How do I do these in Tango?  The change to "{0} {1}" stuff is fine with me, in fact I like it, but this syntax:
> 
>    Stdout.formatln("{0} {1} {2}", a, b, c);
>    Format!(char).convert("{0} {1} {2}", a, b, c);
> 
> Is awkward.  And these statements are used *all the time*.  In a recent toy project I wrote, I used Stdout 15 times, compared to using "foreach" only 8 times.  I also use the "format to string" idiom a lot (oddly enough, not in that project), and it's even more awkward.
> 
> That's why I think phobos really did the "Right Thing" by keeping those
> down to one token.  Second, the fact that the second one does exactly
> what the first does but you need to build a template, etc, is annoying.
>   I kept asking myself if I was doing the right thing because it seemed
> like I was using too much syntax for this kind of operation (I'm still
> not sure it's the best way to go -- is it?)
> 
> I know about Cout as a replacement for the first one, but as far as I can tell it doesn't take parameters, and usually I need some.
> 
> When people ask "why D", I tell them that simpler syntax, better defaults and better garbage collection, each gain us a 50 % reduction in code, and when all three apply to a problem, D can each C++'s lunch. Let's not throw away the simpler syntax.
> 
> (I'm not talking about architecture changes, just wrappers with standardized short names that can become familiar to all D users.)
> 
> 
> 2. toString and toUtf8 (collisions)
> 
> The change of the terminology is actually okay with me.
> 
> But phobos has a way of using toString as both a method and a top-level function name, all over the place.  This gets really clumsy because you can never use the top level function names when writing a class unless you fully qualify them.
> 
> For example, std.cpuid.toString(), always has to be fully qualified when
> called from a class, and seems nondescriptive anyway.  All the
> std.conv.toString() functions are nice but it's easy to accidentally
> call the in-class toString() by accident.
> 
> For the utf8 <--> utf16 and similar, it's frustrating to have to do this:
> 
> dchar[] x32 = ...;
> char[] x8 = tango.text.convert.Utf.toUtf8(x32);
> 
> But you have to fully qualify if you are writing code in any class or struct.  If these were given another name, like makeUtf8, then these collisions would not happen.
> 
> Actually, if it wasn't already out there, I would want to go through all of phobos and remove all the common collisions.  They are much less trouble in an "import" system than in an "include" system, but every time there is a collision it requires an additional "edit-compile" cycle, and/or a fully qualified name.
> 
> And if you forget to import all the right modules, its can impact the correctness angle, because you pick up someone else's "toString" from who knows where.
> 
> I'm just saying, ideally tango should not be duplicating this with toUtf8 etc.
> 
> Kevin

I agree with all that is written above but had not had time to write it up yet.

On Fri, 09 Feb 2007 01:40:00 -0500, Kevin Bealer <kevinbealer@gmail.com> wrote:

>
>Okay -- I'm really sorry if any of this seems to have a negative tone. I hesitate to write this since I have a lot of respect for the Tango design in general, but there are a couple of friction points I've noticed.
>
>1. writefln / format replacements
>
>Concerning standard output and string formatting, in phobos I can do these operations:
>
>   writefln("%s %s %s", a, b, c);
>   format("%s %s %s", a, b, c);
>
>How do I do these in Tango?  The change to "{0} {1}" stuff is fine with me, in fact I like it, but this syntax:
>
>   Stdout.formatln("{0} {1} {2}", a, b, c);
>   Format!(char).convert("{0} {1} {2}", a, b, c);
>
>Is awkward.  And these statements are used *all the time*.  In a recent toy project I wrote, I used Stdout 15 times, compared to using "foreach" only 8 times.  I also use the "format to string" idiom a lot (oddly enough, not in that project), and it's even more awkward.
>
>That's why I think phobos really did the "Right Thing" by keeping those down to one token.  Second, the fact that the second one does exactly what the first does but you need to build a template, etc, is annoying.
>  I kept asking myself if I was doing the right thing because it seemed
>like I was using too much syntax for this kind of operation (I'm still not sure it's the best way to go -- is it?)
>
>I know about Cout as a replacement for the first one, but as far as I can tell it doesn't take parameters, and usually I need some.
>
>When people ask "why D", I tell them that simpler syntax, better defaults and better garbage collection, each gain us a 50 % reduction in code, and when all three apply to a problem, D can each C++'s lunch. Let's not throw away the simpler syntax.
>
>(I'm not talking about architecture changes, just wrappers with standardized short names that can become familiar to all D users.)
>
>
>2. toString and toUtf8 (collisions)
>
>The change of the terminology is actually okay with me.
>
>But phobos has a way of using toString as both a method and a top-level function name, all over the place.  This gets really clumsy because you can never use the top level function names when writing a class unless you fully qualify them.
>
>For example, std.cpuid.toString(), always has to be fully qualified when called from a class, and seems nondescriptive anyway.  All the std.conv.toString() functions are nice but it's easy to accidentally call the in-class toString() by accident.
>
>For the utf8 <--> utf16 and similar, it's frustrating to have to do this:
>
>dchar[] x32 = ...;
>char[] x8 = tango.text.convert.Utf.toUtf8(x32);
>
>But you have to fully qualify if you are writing code in any class or struct.  If these were given another name, like makeUtf8, then these collisions would not happen.
>
>Actually, if it wasn't already out there, I would want to go through all of phobos and remove all the common collisions.  They are much less trouble in an "import" system than in an "include" system, but every time there is a collision it requires an additional "edit-compile" cycle, and/or a fully qualified name.
>
>And if you forget to import all the right modules, its can impact the correctness angle, because you pick up someone else's "toString" from who knows where.
>
>I'm just saying, ideally tango should not be duplicating this with toUtf8 etc.
>
>Kevin

If you really want the 'writefln' and 'format' with Tango, you could do the following:

import tango.io.Stdout;
import tango.text.convert.Format;


Format!(char) format;
typeof(&Stdout.formatln) writefln;

static this()
{
	writefln = &Stdout.formatln;
	format = new Format!(char);
}

void main()
{
	auto str = format("Test {0}: {1}", 1, "Passed");
	writefln(str);
	writefln("Test {0}: {1}", 2, "Passed");
}

Ralf Schneider wrote:

> 
> "Lars Ivar Igesund" <larsivar@igesund.net> schrieb im Newsbeitrag news:eqdcp0$r0s$1@digitaldaemon.com...
>> Frits van Bommel wrote:
>>
>>> Which one to use is hard to say at this point. I've been trying out Tango since its release and I like it but I sometimes miss some parts of Phobos. Whether this is because Phobos is just more familiar to me or actually better is hard to say...
>>
>> Note that what you miss that you feel you have in Phobos, is very much
>> part
>> of the feedback we would like.
> 
> I prefer the string function of phobos over the one provided by Tango.
> A D implementation of the Python string functions (with the same names) I
> would find great.
> 
> - Ralf

Whereas there is much good in the python api, I personally don't think mimicking it in D for the sake of it is the correct approach. Inspiration is another matter. Tango have many string functions, and they may be added to if needs be, but we will do our best to make sure that they are efficient and consistent with the rest of the naming.

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

Kevin Bealer wrote:

> Lars Ivar Igesund wrote:
>> Frits van Bommel wrote:
>> 
>>> Which one to use is hard to say at this point. I've been trying out Tango since its release and I like it but I sometimes miss some parts of Phobos. Whether this is because Phobos is just more familiar to me or actually better is hard to say...
>> 
>> Note that what you miss that you feel you have in Phobos, is very much part of the feedback we would like.
>> 
> 
> Okay -- I'm really sorry if any of this seems to have a negative tone.
> I hesitate to write this since I have a lot of respect for the Tango
> design in general, but there are a couple of friction points I've noticed.
> 
> 1. writefln / format replacements
> 
> Concerning standard output and string formatting, in phobos I can do these operations:
> 
>    writefln("%s %s %s", a, b, c);
>    format("%s %s %s", a, b, c);
> 
> How do I do these in Tango?  The change to "{0} {1}" stuff is fine with me, in fact I like it, but this syntax:
> 
>    Stdout.formatln("{0} {1} {2}", a, b, c);
>    Format!(char).convert("{0} {1} {2}", a, b, c);

I can't give you an immediate solution for the "length" of the Stdout.formatln, but usually one would use tango.text.convert.Sprint for what you use the formatter for. If you only want to print values, there are non-formatting ways to do that. We may be able to give you quicker/easier help over our forum if you have followups? May make it easier for us to integrate solutions into our documentation too if needed.

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