www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - When D is not nice

reply Frank Benoit <keinfarbton googlemail.com> writes:
String concatenation in Java:

"abc " + a + " bla";

where a is an interface ref.

Ported to D, this look like this:

"abc " ~ (cast(Object)a).toString ~ " bla";

This are 3 steps more:
1.) explicit cast to Object (interface/class compatibility!)
2.) explicit call to toString
3.) put additional parentheses

I would be happy if we could remove all three of this annoying points.
Jul 06 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Frank Benoit <keinfarbton googlemail.com> wrote:

 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

interface A { string opCat(string rhs); string opCat_r(string lhs); } class B : A { string opCat(string rhs) { return toString() ~ rhs; } string opCat_r(string lhs) { return lhs ~ toString(); } string toString() { return SomeString; } } This works for me. -- Simen
Jul 06 2008
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Simen Kjaeraas <simen.kjaras gmail.com> wrote:

 This works for me.

But after thinking through it once more, I guess changing the interface definition is not really option, is it? -- Simen
Jul 06 2008
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Simen Kjaeraas schrieb:
 Frank Benoit <keinfarbton googlemail.com> wrote:
 
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

interface A { string opCat(string rhs); string opCat_r(string lhs); } class B : A { string opCat(string rhs) { return toString() ~ rhs; } string opCat_r(string lhs) { return lhs ~ toString(); } string toString() { return SomeString; } } This works for me. -- Simen

My intention was not to ask how to solve it for a certain interface. Instead i was trying to show a flaw in the language design. Even if i would add object.Object method to /every/ interface, then still an interface ref is NOT implicit castable to an Object ref. And i would need to reimplement all those methods in every class that implements the interface.
Jul 06 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Frank Benoit wrote:
 Simen Kjaeraas schrieb:
 Frank Benoit <keinfarbton googlemail.com> wrote:

 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

interface A { string opCat(string rhs); string opCat_r(string lhs); } class B : A { string opCat(string rhs) { return toString() ~ rhs; } string opCat_r(string lhs) { return lhs ~ toString(); } string toString() { return SomeString; } } This works for me. -- Simen

My intention was not to ask how to solve it for a certain interface. Instead i was trying to show a flaw in the language design. Even if i would add object.Object method to /every/ interface, then still an interface ref is NOT implicit castable to an Object ref. And i would need to reimplement all those methods in every class that implements the interface.

That seems to be the price we pay for having interfaces that can be COM interfaces as well. But I'm not sure why I should want to pay that price, having never had a need to call a COM interface in my life. --bb
Jul 06 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
Bill Baxter schrieb:
 That seems to be the price we pay for having interfaces that can be COM 
 interfaces as well.  But I'm not sure why I should want to pay that 
 price, having never had a need to call a COM interface in my life.
 
 --bb

The COM is a /very/ special case, that could be handle with a special solution. The compiler could know about IUnkown and that it is not compatible to Object. That would make D feel much smoother, when dealing a lot with interfaces.
Jul 06 2008
prev sibling parent reply bearophile <bearophileHUGS mailas.com> writes:
Frank Benoit:
 Instead i was trying to show a flaw in the language design.

I think automatic casting of types is a source of troubles. Some times I'd like to remove from D some automatic integer/unsigned casts that D inherits from C. Bye, bearophile
Jul 06 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
bearophile schrieb:
 Frank Benoit:
 Instead i was trying to show a flaw in the language design.

I think automatic casting of types is a source of troubles. Some times I'd like to remove from D some automatic integer/unsigned casts that D inherits from C. Bye, bearophile

I think class/interface compatibility is not going to introduce trouble. With the exception of COM, every interface IS an Object. The missing compatibility makes the basic object functionality missing. That makes trouble with .toString as shown, with container that want to use opCmp/opEquals or functions that just want an Object of any type: void store(Object o); but i need a cast for interface: store( cast(Object)a ); Yuck!
Jul 06 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Frank Benoit a écrit :
 String concatenation in Java:
 
 "abc " + a + " bla";
 
 where a is an interface ref.
 
 Ported to D, this look like this:
 
 "abc " ~ (cast(Object)a).toString ~ " bla";
 
 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses
 
 I would be happy if we could remove all three of this annoying points.

Exactly the same thought here. Also: int i = ...; char[] x = "You pressed button " + i; Oops... doesn't compile. To fix it: import std.string; int i = ...; char[] x = "You pressed button " + toString(i); But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing: import std.string; int i = ...; char[] x = "You pressed button " + std.string.toString(i); Those are the cases I find D not nice.
Jul 06 2008
next sibling parent reply superdan <super dan.org> writes:
Ary Borenszweig Wrote:

 Frank Benoit a écrit :
 String concatenation in Java:
 
 "abc " + a + " bla";
 
 where a is an interface ref.
 
 Ported to D, this look like this:
 
 "abc " ~ (cast(Object)a).toString ~ " bla";
 
 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses
 
 I would be happy if we could remove all three of this annoying points.

Exactly the same thought here. Also: int i = ...; char[] x = "You pressed button " + i; Oops... doesn't compile. To fix it: import std.string; int i = ...; char[] x = "You pressed button " + toString(i); But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing: import std.string; int i = ...; char[] x = "You pressed button " + std.string.toString(i); Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write: auto x = asStr("You pressed button ", i, " with your pinky toe");
Jul 06 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
superdan wrote:
 Ary Borenszweig Wrote:
 
 Frank Benoit a écrit :
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

int i = ...; char[] x = "You pressed button " + i; Oops... doesn't compile. To fix it: import std.string; int i = ...; char[] x = "You pressed button " + toString(i); But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing: import std.string; int i = ...; char[] x = "You pressed button " + std.string.toString(i); Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write: auto x = asStr("You pressed button ", i, " with your pinky toe");

This is also known as std.string.format.
Jul 06 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
downs a crit :
 superdan wrote:
 Ary Borenszweig Wrote:

 Frank Benoit a écrit :
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

int i = ...; char[] x = "You pressed button " + i; Oops... doesn't compile. To fix it: import std.string; int i = ...; char[] x = "You pressed button " + toString(i); But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing: import std.string; int i = ...; char[] x = "You pressed button " + std.string.toString(i); Those are the cases I find D not nice.

auto x = asStr("You pressed button ", i, " with your pinky toe");

This is also known as std.string.format.

But concatenating such things is so common... Instead of doing what it is obvious, you get an error. At least built-in types should have opCat and opCat_r defined like that.
Jul 06 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:g4rhq1$1i7a$1 digitalmars.com...

 But concatenating such things is so common... Instead of doing what it is 
 obvious, you get an error. At least built-in types should have opCat and 
 opCat_r defined like that.

Common in many languages, yes. Convenient, yes. But it's a pointless hole in the type system that I don't want to see opened. Having used D for a while, I've come to appreciate using a function to do formatting rather than string concatenation. It's more flexible and can be more efficient, and doesn't take that much more typing.
Jul 06 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley a crit :
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:g4rhq1$1i7a$1 digitalmars.com...
 
 But concatenating such things is so common... Instead of doing what it is 
 obvious, you get an error. At least built-in types should have opCat and 
 opCat_r defined like that.

Common in many languages, yes. Convenient, yes. But it's a pointless hole in the type system that I don't want to see opened. Having used D for a while, I've come to appreciate using a function to do formatting rather than string concatenation. It's more flexible and can be more efficient, and doesn't take that much more typing.

How is it a pointless hole in the type system? I thought having "~" be the concatenation operator instead of "+" was just to prevent that hole.
Jul 06 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:g4rsi1$2cnt$1 digitalmars.com...
 How is it a pointless hole in the type system? I thought having "~" be the 
 concatenation operator instead of "+" was just to prevent that hole.

It's a bunch of special cases and a weakening of the type system in one area for no benefit that I can see short of a few saved keystrokes. The semantics of the concatenation operator would have to be changed for string types (char[], wchar[], dchar[] -- and any permutation of const and invariant of those in D2), but not for any other array types, which is ugly. It also unnecessarily complicates the semantics and lookup rules for opCat, opCat_r, and opCatAssign for user-defined types. From an entirely cosmetic standpoint, I have a clear preference for: format("x is {}, y is {}, z is {}", x, y, z) vs. "x is " ~ x ~ ", y is " ~ y ~ ", z is " ~ z Concatenation also tends to make (unexperienced) people do stupid things like writeln("x is " ~ x); which creates a completely unnecessary string temporary, but they think that that's the only way to output a number. I really cannot see any benefit from allowing concatenation of strings and non-strings (and non-characters).
Jul 06 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jarrett Billingsley wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:g4rsi1$2cnt$1 digitalmars.com...
 How is it a pointless hole in the type system? I thought having "~" be the 
 concatenation operator instead of "+" was just to prevent that hole.

It's a bunch of special cases and a weakening of the type system in one area for no benefit that I can see short of a few saved keystrokes. The semantics of the concatenation operator would have to be changed for string types (char[], wchar[], dchar[] -- and any permutation of const and invariant of those in D2), but not for any other array types, which is ugly.

But a string (as in the string data type, conceptually) is already a special case. It just happens that in D a string is implemented as a char[] (or wchar[], dchar[]). I wouldn't mind if there were concatenation operators for these kinds of arrays only. Although it does it does make me wonder if it would be better for a string to be a special type, such as a struct wrapping a char[], etc.. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 27 2008
prev sibling parent reply superdan <super dan.org> writes:
downs Wrote:

 superdan wrote:
 Ary Borenszweig Wrote:
 
 Frank Benoit a écrit :
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

int i = ...; char[] x = "You pressed button " + i; Oops... doesn't compile. To fix it: import std.string; int i = ...; char[] x = "You pressed button " + toString(i); But wait, if that piece of code is inside a method of a class, than (WHY?) it thinks it's the toString() method, so you end up writing: import std.string; int i = ...; char[] x = "You pressed button " + std.string.toString(i); Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write: auto x = asStr("You pressed button ", i, " with your pinky toe");

This is also known as std.string.format.

narp that interprets %s and shit which can quickly become dangerous. you'd have to say auto x = format("", ........); i also agree with ary that infix could help a ton. but then it would confuse noobs. can't please everyone. life's a bitch.
Jul 06 2008
parent reply superdan <super dan.org> writes:
Koroskin Denis Wrote:

 On Mon, 07 Jul 2008 03:12:27 +0400, superdan <super dan.org> wrote:
 
 downs Wrote:

 superdan wrote:
 Ary Borenszweig Wrote:

 Frank Benoit a écrit :
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying  



 Exactly the same thought here. Also:

 int i = ...;
 char[] x = "You pressed button " + i;

 Oops... doesn't compile. To fix it:

 import std.string;

 int i = ...;
 char[] x = "You pressed button " + toString(i);

 But wait, if that piece of code is inside a method of a class, than
 (WHY?) it thinks it's the toString() method, so you end up writing:

 import std.string;

 int i = ...;
 char[] x = "You pressed button " + std.string.toString(i);

 Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts

 auto x = asStr("You pressed button ", i, " with your pinky toe");

This is also known as std.string.format.

narp that interprets %s and shit which can quickly become dangerous.

No, unlike printf-family functions, writef/std.string.format and other D counterparts *are* type-safe, so you can use %s with strings, ints, longs, Objects, i.e. with just _anything_.

narp i meant something else. maybe dangerous was not the appropriate word. let's say surprising. import std.stdio, std.string; void main() { string shit = "I embed a %s thing"; // ... writeln(format("innocent formatting string ", shit)); } this will fail dynamically. the problem is that any string argument is searched for %. that bad behavior was fixed in writefln but not in string.format. writefln only parses its first string for % shit but not the others. as it should.
 you'd have to say

 auto x = format("", ........);

class Dude {} auto greeting = format("Hello, %s!", new Dude());

not sure what that illustrates but i also realize my fix was wrong. again all strings will be parsed for % shit. that blows.
Jul 07 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"superdan" <super dan.org> wrote in message 
news:g4u4t3$1aln$1 digitalmars.com...
 Koroskin Denis Wrote:

 On Mon, 07 Jul 2008 03:12:27 +0400, superdan <super dan.org> wrote:

 downs Wrote:

 superdan wrote:
 Ary Borenszweig Wrote:

 Frank Benoit a écrit :
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying



 Exactly the same thought here. Also:

 int i = ...;
 char[] x = "You pressed button " + i;

 Oops... doesn't compile. To fix it:

 import std.string;

 int i = ...;
 char[] x = "You pressed button " + toString(i);

 But wait, if that piece of code is inside a method of a class, than
 (WHY?) it thinks it's the toString() method, so you end up writing:

 import std.string;

 int i = ...;
 char[] x = "You pressed button " + std.string.toString(i);

 Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts

 auto x = asStr("You pressed button ", i, " with your pinky toe");

This is also known as std.string.format.

narp that interprets %s and shit which can quickly become dangerous.

No, unlike printf-family functions, writef/std.string.format and other D counterparts *are* type-safe, so you can use %s with strings, ints, longs, Objects, i.e. with just _anything_.

narp i meant something else. maybe dangerous was not the appropriate word. let's say surprising. import std.stdio, std.string; void main() { string shit = "I embed a %s thing"; // ... writeln(format("innocent formatting string ", shit)); } this will fail dynamically. the problem is that any string argument is searched for %. that bad behavior was fixed in writefln but not in string.format. writefln only parses its first string for % shit but not the others. as it should.

If that's true and hasn't been fixed, you should probably submit a bugzilla report if you/someone else hasn't already.
Jul 07 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:g4uip0$2ag1$1 digitalmars.com...

 import std.stdio, std.string;

 void main()
 {
    string shit = "I embed a %s thing";
    // ...
    writeln(format("innocent formatting string ", shit));
 }

 this will fail dynamically. the problem is that any string argument is 
 searched for %. that bad behavior was fixed in writefln but not in 
 string.format. writefln only parses its first string for % shit but not 
 the others. as it should.

If that's true and hasn't been fixed, you should probably submit a bugzilla report if you/someone else hasn't already.

It's true and expected behavior in phobos 1. All strings are interpreted as format strings unless they themselves are formatted into another string using %s. Phobos 2 only interprets the first parameter as a format string, so it won't break there.
Jul 07 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g4ujs8$2d2m$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:g4uip0$2ag1$1 digitalmars.com...

 import std.stdio, std.string;

 void main()
 {
    string shit = "I embed a %s thing";
    // ...
    writeln(format("innocent formatting string ", shit));
 }

 this will fail dynamically. the problem is that any string argument is 
 searched for %. that bad behavior was fixed in writefln but not in 
 string.format. writefln only parses its first string for % shit but not 
 the others. as it should.

If that's true and hasn't been fixed, you should probably submit a bugzilla report if you/someone else hasn't already.

It's true and expected behavior in phobos 1. All strings are interpreted as format strings unless they themselves are formatted into another string using %s. Phobos 2 only interprets the first parameter as a format string, so it won't break there.

Actually that seems only to be writefln in Phobos 2, not sure about format.
Jul 07 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
superdan, el  6 de julio a las 18:12 me escribiste:
 Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write: auto x = asStr("You pressed button ", i, " with your pinky toe");

That sounds like a poor's man version of the python's built-in formatting capabilities: x = "You pressed button %d with your pinky toe" % i -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Dale tu mano al mono, pero no el codo, dado que un mono confianzudo es irreversible. -- Ricardo Vaporeso. La Reja, Agosto de 1912.
Jul 07 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20080707163413.GB17001 burns.springfield.home...
 superdan, el  6 de julio a las 18:12 me escribiste:
 Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts everything to string and concats. then you write: auto x = asStr("You pressed button ", i, " with your pinky toe");

That sounds like a poor's man version of the python's built-in formatting capabilities: x = "You pressed button %d with your pinky toe" % i

What can python's formatting operator do that std.string.format cannot?
Jul 07 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  7 de julio a las 12:37 me escribiste:
 auto x = asStr("You pressed button ", i, " with your pinky toe");

That sounds like a poor's man version of the python's built-in formatting capabilities: x = "You pressed button %d with your pinky toe" % i

What can python's formatting operator do that std.string.format cannot?

Nothing I guess. I was talking about the nicer syntax =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- You can do better than me. You could throw a dart out the window and hit someone better than me. I'm no good! -- George Constanza
Jul 07 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Mon, 07 Jul 2008 03:12:27 +0400, superdan <super dan.org> wrote:

 downs Wrote:

 superdan wrote:
 Ary Borenszweig Wrote:

 Frank Benoit a écrit :
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying  



 Exactly the same thought here. Also:

 int i = ...;
 char[] x = "You pressed button " + i;

 Oops... doesn't compile. To fix it:

 import std.string;

 int i = ...;
 char[] x = "You pressed button " + toString(i);

 But wait, if that piece of code is inside a method of a class, than
 (WHY?) it thinks it's the toString() method, so you end up writing:

 import std.string;

 int i = ...;
 char[] x = "You pressed button " + std.string.toString(i);

 Those are the cases I find D not nice.

yarp i concur. phobos oughtta have a function asStr that converts

 auto x = asStr("You pressed button ", i, " with your pinky toe");

This is also known as std.string.format.

narp that interprets %s and shit which can quickly become dangerous.

No, unlike printf-family functions, writef/std.string.format and other D counterparts *are* type-safe, so you can use %s with strings, ints, longs, Objects, i.e. with just _anything_.
 you'd have to say

 auto x = format("", ........);

class Dude {} auto greeting = format("Hello, %s!", new Dude());
 i also agree with ary that infix could help a ton. but then it would  
 confuse noobs. can't please everyone. life's a bitch.

Jul 07 2008
prev sibling next sibling parent superdan <super dan.org> writes:
Frank Benoit Wrote:

 String concatenation in Java:
 
 "abc " + a + " bla";
 
 where a is an interface ref.
 
 Ported to D, this look like this:
 
 "abc " ~ (cast(Object)a).toString ~ " bla";
 
 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses
 
 I would be happy if we could remove all three of this annoying points.

so interfaces are not Objects. actually they have no common ancestor. that's pretty much fuckshat-up. damn.
Jul 06 2008
prev sibling next sibling parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
Frank Benoit wrote:

 "abc " + a + " bla";

 I would be happy if we could remove all three of this annoying
 points. 

This seems as you want to give up strong typing. The next one may come up with x= 2 + a + 4; where a is an interface and requires that a should be easily transformable for not geetting any error. Would you allow or forbid that? -manfred
Jul 06 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Manfred_Nowak schrieb:
 Frank Benoit wrote:
 
 "abc " + a + " bla";

 I would be happy if we could remove all three of this annoying
 points. 

This seems as you want to give up strong typing. The next one may come up with x= 2 + a + 4; where a is an interface and requires that a should be easily transformable for not geetting any error. Would you allow or forbid that? -manfred

No, i don't want to give up strong typing. Primarily i wanted to show that class/interface incompatibility is bad IMHO. So i would say, 1.) is an important issue, 3.) is annoying and 2.) would be nice syntax sugar.
Jul 07 2008
parent "Manfred_Nowak" <svv1999 hotmail.com> writes:
Frank Benoit wrote:

 So i would say, 1.) is an important issue

I agree with the importance. But my first thought was, that even explicit conversion of an interface to an `Object' should not enrich the functionality of the object referenced through the interface. This contradicts your wishes. But because at present I have no arguments supporting my first thought, please handle my post as a remark only. -manfred
Jul 07 2008
prev sibling next sibling parent "David Wilson" <dw botanicus.net> writes:
Q29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIGJ1dCBJIHRoaW5rIHRoZSBmb3J0aGNvbWluZyBzdXBw
b3J0IGZvcgpvdmVybG9hZCBzZXRzIGFuZCBmcmVlIGZ1bmN0aW9ucyB3aWxsIGFsbG93IGRlZmlu
aXRpb24gb2YgYSBzaW1wbGUKbW9kdWxlIHRvIGFsbGV2aWF0ZSB0aGlzLgoKaW1wb3J0IHNvbWV3
aGVyZS5lYXN5Y29uY2F0OwoKZGVmaW5pbmcgYSBidW5jaCBvZiBleHRyYSBvcENhdHMgZm9yIHNp
bXBsZSB0eXBlcy4KCgpPbiBTdW4sIEp1bCA2LCAyMDA4IGF0IDk6MzAgUE0sIEZyYW5rIEJlbm9p
dCA8a2VpbmZhcmJ0b25AZ29vZ2xlbWFpbC5jb20+IHdyb3RlOgo+IFN0cmluZyBjb25jYXRlbmF0
aW9uIGluIEphdmE6Cj4KPiAiYWJjICIgKyBhICsgIiBibGEiOwo+Cj4gd2hlcmUgYSBpcyBhbiBp
bnRlcmZhY2UgcmVmLgo+Cj4gUG9ydGVkIHRvIEQsIHRoaXMgbG9vayBsaWtlIHRoaXM6Cj4KPiAi
YWJjICIgfiAoY2FzdChPYmplY3QpYSkudG9TdHJpbmcgfiAiIGJsYSI7Cj4KPiBUaGlzIGFyZSAz
IHN0ZXBzIG1vcmU6Cj4gMS4pIGV4cGxpY2l0IGNhc3QgdG8gT2JqZWN0IChpbnRlcmZhY2UvY2xh
c3MgY29tcGF0aWJpbGl0eSEpCj4gMi4pIGV4cGxpY2l0IGNhbGwgdG8gdG9TdHJpbmcKPiAzLikg
cHV0IGFkZGl0aW9uYWwgcGFyZW50aGVzZXMKPgo+IEkgd291bGQgYmUgaGFwcHkgaWYgd2UgY291
bGQgcmVtb3ZlIGFsbCB0aHJlZSBvZiB0aGlzIGFubm95aW5nIHBvaW50cy4KPgoKCgotLSAKU2Np
ZW5jZSB3aXRob3V0IHJlbGlnaW9uIGlzIGxhbWUsIHJlbGlnaW9uIHdpdGhvdXQgc2NpZW5jZSBp
cyBibGluZC4KIOKAlCBFaW5zdGVpbgo=
Jul 07 2008
prev sibling parent reply JAnderson <ask me.com> writes:
Frank Benoit wrote:
 String concatenation in Java:
 
 "abc " + a + " bla";
 
 where a is an interface ref.
 
 Ported to D, this look like this:
 
 "abc " ~ (cast(Object)a).toString ~ " bla";
 
 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses
 
 I would be happy if we could remove all three of this annoying points.

I agree, string handling could be better its such a common operation. Its one of worst things to work with in C++. Implicit string conversions would make things much easier and more readable. -Joel
Jul 07 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
JAnderson wrote:
 Frank Benoit wrote:
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

I agree, string handling could be better its such a common operation. Its one of worst things to work with in C++. Implicit string conversions would make things much easier and more readable. -Joel

I think STL solves this quite nicely with std::ostringstream ... Though I might be misunderstanding you... Tomas
Jul 08 2008
parent JAnderson <ask me.com> writes:
Tomas Lindquist Olsen wrote:
 JAnderson wrote:
 Frank Benoit wrote:
 String concatenation in Java:

 "abc " + a + " bla";

 where a is an interface ref.

 Ported to D, this look like this:

 "abc " ~ (cast(Object)a).toString ~ " bla";

 This are 3 steps more:
 1.) explicit cast to Object (interface/class compatibility!)
 2.) explicit call to toString
 3.) put additional parentheses

 I would be happy if we could remove all three of this annoying points.

I agree, string handling could be better its such a common operation. Its one of worst things to work with in C++. Implicit string conversions would make things much easier and more readable. -Joel

I think STL solves this quite nicely with std::ostringstream ... Though I might be misunderstanding you... Tomas

I don;t like std::ostringstream. - Its hard to debug. - Your always converting one string to a std::string (and then perhaps a C string) . You can't pass it into a function that takes a string ie: foo("test" << 5); //You couldn't do this for instance. And this is very useful. - You have to define a specific overload for every special case. These are not as reuseable in other cases as a common sense ".ToString()" - It doesn't allocate very effectively. - You have to include the large std::ostringstream. - A personal preference: I think std::ostringstream (and its variants) are ugly. In particular the shift operations are nasty. - You can't remove a piece of another string very easily (string manipulation and transforms). Lets compare: #include <sstream> ... ostringstream oss; oss << str << t2; std::string result=oss.str(); Foo(result.c_str()); *sign* ok you could do this: ostringstream oss; oss << str << t2; Foo(oss.str().c_str()); To: Foo(str ~ T2); What would you prefer? Don't get me wrong. I do use std::ostringstream however its just I don't like it compared to say... VB. I use this in C++ normally: template <class out_type, class in_value> out_type convert(const in_value & t) { stringstream stream; stream << t; // insert value to stream out_type result; // store conversions result here stream >> result; // write value to result return result; } ... Foo((str + convert(T2)).c_str()); All I want to do is send a dam message with some value attached to the end. I shouldn't have to jump though hoops to do so. -Joel
Jul 10 2008