"h3r3tic" <h3r3tic@dev.null> wrote in message news:cg63u0$v8v$1@digitaldaemon.com...
> Matthew wrote:
> > You could swritef(), which would be clear, and would probably be less abusive to the heap to boot!
>
> but it's still so C-ish. being able to do  "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP.

Ah yes, but I think it's been suggested previously many times that the infix string concatenation operator should automatically call toString() on any of its arguments that are not already strings, prior to concatenation. Hence:

    Object    person  =     new Person("Walter", "Bright");
    long        factor    =    20;

    "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man";

would cause the call of std.string.toString(long) and Person.toString(), so we'd get:

    "The IQ of Walter Bright is 20 times that of mortal man":

Although I'm one of those that consistently opposes the overloading of << and >>, this is a different case, since every Object has the facility to toString() itself, and the built-ins are already covered. It wouldn't work for structs, but then that's a good thing anyway. For enums, you would provide a suitable toString() in the same module as the enum, and the compiler would use that.

btw, if I'm wrong in saying it's been suggested before, I suggest it now.

The problems with that particular approach are twofold:

1) enforcing the binding of Phobos via std.string.toString(). There's a few
issues with doing that, but it's perhaps a matter of personal taste rather
than technicalities such as namespace pollution (which std.* is terribly
good at).

2) more importantly: it doesn't work for unicode strings, because providing
a "dchar toString()" in each class is not covariant with the "char
toString()" living in the root Object. I wish there was an nice, clean,
elegant solution to this ...


"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com...
>
> "h3r3tic" <h3r3tic@dev.null> wrote in message
news:cg63u0$v8v$1@digitaldaemon.com...
> > Matthew wrote:
> > > You could swritef(), which would be clear, and would probably be less
abusive to the heap to boot!
> >
> > but it's still so C-ish. being able to do  "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP.
>
> Ah yes, but I think it's been suggested previously many times that the
infix string concatenation operator should
> automatically call toString() on any of its arguments that are not already
strings, prior to concatenation. Hence:
>
>     Object    person  =     new Person("Walter", "Bright");
>     long        factor    =    20;
>
>     "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man";
>
> would cause the call of std.string.toString(long) and Person.toString(),
so we'd get:
>
>     "The IQ of Walter Bright is 20 times that of mortal man":
>
> Although I'm one of those that consistently opposes the overloading of <<
and >>, this is a different case, since every
> Object has the facility to toString() itself, and the built-ins are
already covered. It wouldn't work for structs, but
> then that's a good thing anyway. For enums, you would provide a suitable
toString() in the same module as the enum, and
> the compiler would use that.
>
> btw, if I'm wrong in saying it's been suggested before, I suggest it now.
>
>
>

"antiAlias" <fu@bar.com> wrote in message news:cg68tk$11on$1@digitaldaemon.com...
> The problems with that particular approach are twofold:
>
> 1) enforcing the binding of Phobos via std.string.toString(). There's a few
> issues with doing that, but it's perhaps a matter of personal taste rather
> than technicalities such as namespace pollution (which std.* is terribly
> good at).
>
> 2) more importantly: it doesn't work for unicode strings, because providing
> a "dchar toString()" in each class is not covariant with the "char
> toString()" living in the root Object. I wish there was an nice, clean,
> elegant solution to this ...

Doh! Yes, silly me and my anglophoneaphiling.

I'm sure there's an elegant solution out there worth having though. It'd make things much simpler in many ways. It'd also make D amenable to the Fast String Concatenation technique (which a certain mouthy pommie invented ...).

>
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com...
> >
> > "h3r3tic" <h3r3tic@dev.null> wrote in message
> news:cg63u0$v8v$1@digitaldaemon.com...
> > > Matthew wrote:
> > > > You could swritef(), which would be clear, and would probably be less
> abusive to the heap to boot!
> > >
> > > but it's still so C-ish. being able to do  "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP.
> >
> > Ah yes, but I think it's been suggested previously many times that the
> infix string concatenation operator should
> > automatically call toString() on any of its arguments that are not already
> strings, prior to concatenation. Hence:
> >
> >     Object    person  =     new Person("Walter", "Bright");
> >     long        factor    =    20;
> >
> >     "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man";
> >
> > would cause the call of std.string.toString(long) and Person.toString(),
> so we'd get:
> >
> >     "The IQ of Walter Bright is 20 times that of mortal man":
> >
> > Although I'm one of those that consistently opposes the overloading of <<
> and >>, this is a different case, since every
> > Object has the facility to toString() itself, and the built-ins are
> already covered. It wouldn't work for structs, but
> > then that's a good thing anyway. For enums, you would provide a suitable
> toString() in the same module as the enum, and
> > the compiler would use that.
> >
> > btw, if I'm wrong in saying it's been suggested before, I suggest it now.
> >
> >
> >
>
>

Agreed. I'd really like to see automatic conversion through an operator. The tricky part is dealing with optional format-specifiers: think of dates, for example. How does one pass a format-specifier to the opString() method, while doing this:

Date date = new Date (milliseconds_since_1970);

char[] string = "The date is " ~ date;

And what about floating-point?

Perhaps you have to set the format in advance ?

Java only has one char type, so they can get away with this more easily. What does C# do?


"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg69c1$120n$1@digitaldaemon.com...
>
> "antiAlias" <fu@bar.com> wrote in message
news:cg68tk$11on$1@digitaldaemon.com...
> > The problems with that particular approach are twofold:
> >
> > 1) enforcing the binding of Phobos via std.string.toString(). There's a
few
> > issues with doing that, but it's perhaps a matter of personal taste
rather
> > than technicalities such as namespace pollution (which std.* is terribly
> > good at).
> >
> > 2) more importantly: it doesn't work for unicode strings, because
providing
> > a "dchar toString()" in each class is not covariant with the "char
> > toString()" living in the root Object. I wish there was an nice, clean,
> > elegant solution to this ...
>
> Doh! Yes, silly me and my anglophoneaphiling.
>
> I'm sure there's an elegant solution out there worth having though. It'd
make things much simpler in many ways. It'd
> also make D amenable to the Fast String Concatenation technique (which a
certain mouthy pommie invented ...).
>
> >
> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com...
> > >
> > > "h3r3tic" <h3r3tic@dev.null> wrote in message
> > news:cg63u0$v8v$1@digitaldaemon.com...
> > > > Matthew wrote:
> > > > > You could swritef(), which would be clear, and would probably be
less
> > abusive to the heap to boot!
> > > >
> > > > but it's still so C-ish. being able to do  "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP.
> > >
> > > Ah yes, but I think it's been suggested previously many times that the
> > infix string concatenation operator should
> > > automatically call toString() on any of its arguments that are not
already
> > strings, prior to concatenation. Hence:
> > >
> > >     Object    person  =     new Person("Walter", "Bright");
> > >     long        factor    =    20;
> > >
> > >     "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal
man";
> > >
> > > would cause the call of std.string.toString(long) and
Person.toString(),
> > so we'd get:
> > >
> > >     "The IQ of Walter Bright is 20 times that of mortal man":
> > >
> > > Although I'm one of those that consistently opposes the overloading of
<<
> > and >>, this is a different case, since every
> > > Object has the facility to toString() itself, and the built-ins are
> > already covered. It wouldn't work for structs, but
> > > then that's a good thing anyway. For enums, you would provide a
suitable
> > toString() in the same module as the enum, and
> > > the compiler would use that.
> > >
> > > btw, if I'm wrong in saying it's been suggested before, I suggest it
now.
> > >
> > >
> > >
> >
> >
>
>

"antiAlias" <fu@bar.com> wrote in message news:cg68tk$11on$1@digitaldaemon.com...
> The problems with that particular approach are twofold:
>
> 1) enforcing the binding of Phobos via std.string.toString(). There's a few
> issues with doing that, but it's perhaps a matter of personal taste rather
> than technicalities such as namespace pollution (which std.* is terribly
> good at).
>
> 2) more importantly: it doesn't work for unicode strings, because providing
> a "dchar toString()" in each class is not covariant with the "char
> toString()" living in the root Object. I wish there was an nice, clean,
> elegant solution to this ...

Easy(-ish). It takes its lead from the leftmost concatenation thingy. In abscense of a leading string, it assumes char[].

Of course, this still requires use of argument-based string-type deduction, as in

    char[] toString(int , char[]);
    dchar[] toString(int, dchar[]);

but I reckon that facility is going to be needed anyway.

>
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com...
> >
> > "h3r3tic" <h3r3tic@dev.null> wrote in message
> news:cg63u0$v8v$1@digitaldaemon.com...
> > > Matthew wrote:
> > > > You could swritef(), which would be clear, and would probably be less
> abusive to the heap to boot!
> > >
> > > but it's still so C-ish. being able to do  "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP.
> >
> > Ah yes, but I think it's been suggested previously many times that the
> infix string concatenation operator should
> > automatically call toString() on any of its arguments that are not already
> strings, prior to concatenation. Hence:
> >
> >     Object    person  =     new Person("Walter", "Bright");
> >     long        factor    =    20;
> >
> >     "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal man";
> >
> > would cause the call of std.string.toString(long) and Person.toString(),
> so we'd get:
> >
> >     "The IQ of Walter Bright is 20 times that of mortal man":
> >
> > Although I'm one of those that consistently opposes the overloading of <<
> and >>, this is a different case, since every
> > Object has the facility to toString() itself, and the built-ins are
> already covered. It wouldn't work for structs, but
> > then that's a good thing anyway. For enums, you would provide a suitable
> toString() in the same module as the enum, and
> > the compiler would use that.
> >
> > btw, if I'm wrong in saying it's been suggested before, I suggest it now.
> >
> >
> >
>
>

h3r3tic wrote:

> disclaimer: sorry if it has been mentioned before
> 
> 
> how about adapting the $ token to convert anything to a string ? like
> 
> int foo = 5;
> char[] bar = $foo;
> 
> // bar == "5"
> 
> i dont think this would be a large problem to implement whilst BASIC dudes would instantly know it's sth bout strings :] in BASIC you read a$ as 'a string'.
> 
> that's my vote in the $ war ;]

I think $ should be left unused.  Metaprogramming tools like Lex, Yacc, SWIG, and ANTLR frequently receive code snippets which are injected into their output.  They give special meaning to $ because C doesn't.

Assigning meaning to $ would make using these tools in conjunction with D more cumbersome.

 -- andy

In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says...

>providing
>a "dchar toString()" in each class is not covariant with the "char
>toString()" living in the root Object.

What does covariant mean exactly?

"Batman" <Batman_member@pathlink.com> wrote in message news:cg6pcs$1cch$1@digitaldaemon.com...
> In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says...
>
> >providing
> >a "dchar toString()" in each class is not covariant with the "char
> >toString()" living in the root Object.
>
> What does covariant mean exactly?

Well, I won't profer a definition of the word, but it is usually used in software engineering to describe the following condition

class B
{}
class D : public B
{}

class X
{
    virtual B clone();
}

class Y : public X
{
    virtual D clone();
}

Because D is (publicly) derived from B, it is legitimate for Y's overload of X's clone() method to return D instead of
B.

This is because inheritance is an "Is-A" relationship. Hence, any D is-a B.

Since X's clone() requires a B, Y's clone() can return a D, because a D is-a B.

Make sense? (I hope so, 'cos that's my top shelf explanation. You'll have to hope for other posts if not. <G>)

"antiAlias" <fu@bar.com> wrote in message news:cg6ccg$139m$1@digitaldaemon.com...
> Agreed. I'd really like to see automatic conversion through an operator. The tricky part is dealing with optional format-specifiers: think of dates, for example. How does one pass a format-specifier to the opString() method, while doing this:
>
> Date date = new Date (milliseconds_since_1970);
>
> char[] string = "The date is " ~ date;
>
> And what about floating-point?
>
> Perhaps you have to set the format in advance ?

No. If people want formatting, they can use sprintf() or swritef().


I only think this is workable if the compiler *only* interprets ~ as a call to toString(), which it will either pick if up from the current module or the module of the convertee type or std.string, in that order.


I'll turn into an opponent of this idea if we start to move towards an IOStreams kind of thing, with all that hideous setw() manipulator crap.

> Java only has one char type, so they can get away with this more easily. What does C# do?

IIRC, it calls the ToString() method. I think there's also IFormatter stuff, but it's been a long time since I had a play, and even then it wasn't that interesting. ;)


>
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg69c1$120n$1@digitaldaemon.com...
> >
> > "antiAlias" <fu@bar.com> wrote in message
> news:cg68tk$11on$1@digitaldaemon.com...
> > > The problems with that particular approach are twofold:
> > >
> > > 1) enforcing the binding of Phobos via std.string.toString(). There's a
> few
> > > issues with doing that, but it's perhaps a matter of personal taste
> rather
> > > than technicalities such as namespace pollution (which std.* is terribly
> > > good at).
> > >
> > > 2) more importantly: it doesn't work for unicode strings, because
> providing
> > > a "dchar toString()" in each class is not covariant with the "char
> > > toString()" living in the root Object. I wish there was an nice, clean,
> > > elegant solution to this ...
> >
> > Doh! Yes, silly me and my anglophoneaphiling.
> >
> > I'm sure there's an elegant solution out there worth having though. It'd
> make things much simpler in many ways. It'd
> > also make D amenable to the Fast String Concatenation technique (which a
> certain mouthy pommie invented ...).
> >
> > >
> > >
> > > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg65e6$100p$1@digitaldaemon.com...
> > > >
> > > > "h3r3tic" <h3r3tic@dev.null> wrote in message
> > > news:cg63u0$v8v$1@digitaldaemon.com...
> > > > > Matthew wrote:
> > > > > > You could swritef(), which would be clear, and would probably be
> less
> > > abusive to the heap to boot!
> > > > >
> > > > > but it's still so C-ish. being able to do  "foo " ~ 5 ~ whatever ~ " bar" would be a GoodThing for projects like DSP.
> > > >
> > > > Ah yes, but I think it's been suggested previously many times that the
> > > infix string concatenation operator should
> > > > automatically call toString() on any of its arguments that are not
> already
> > > strings, prior to concatenation. Hence:
> > > >
> > > >     Object    person  =     new Person("Walter", "Bright");
> > > >     long        factor    =    20;
> > > >
> > > >     "The IQ of" ~ person ~ " is " ~ factor ~ " times that of mortal
> man";
> > > >
> > > > would cause the call of std.string.toString(long) and
> Person.toString(),
> > > so we'd get:
> > > >
> > > >     "The IQ of Walter Bright is 20 times that of mortal man":
> > > >
> > > > Although I'm one of those that consistently opposes the overloading of
> <<
> > > and >>, this is a different case, since every
> > > > Object has the facility to toString() itself, and the built-ins are
> > > already covered. It wouldn't work for structs, but
> > > > then that's a good thing anyway. For enums, you would provide a
> suitable
> > > toString() in the same module as the enum, and
> > > > the compiler would use that.
> > > >
> > > > btw, if I'm wrong in saying it's been suggested before, I suggest it
> now.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

antiAlias wrote:
> Agreed. I'd really like to see automatic conversion through an operator. The
> tricky part is dealing with optional format-specifiers: think of dates, for
> example. How does one pass a format-specifier to the opString() method,
> while doing this:
> 
> Date date = new Date (milliseconds_since_1970);
> 
> char[] string = "The date is " ~ date;
> 
> And what about floating-point?
> 
> Perhaps you have to set the format in advance ?
> 
> Java only has one char type, so they can get away with this more easily.
> What does C# do?

C# "primitive" types aren't.  They still inherit Object.  The runtime just optimizes them a bit differently when possible. :)

(everything has a ToString method: ints, strings, arrays, even pointers)

 -- andy