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
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.


 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");
 


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.


 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");


 
 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.


 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");
 


 
 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 "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  






 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");


 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
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  






 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");


 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






 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");


 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 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 conversion’s 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