I am talking about automatic string conversion. Even Java has it!

char []s;
int n;

why not?
s=s~n;

This is one thing that java is far better than D, I must sadly say.

Right now I have a line in my code:
xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ",
"$a="~toString(i1),"$b=
"~toString(ids)));

but why not
xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ", "$a="~i1,"$b=
"ids));

Ok, I have 2 sql vars here, but what I had 10? What a mess would my code be.

I know that automatic conversion might be a bit confusing, but it adds so much to the readability of code.

D has done so much to simplify reading and writing of code, why stop now?

So why not?

"M" <M_member@pathlink.com> wrote in message news:das2qq$2j5g$1@digitaldaemon.com...
> but why not
> xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ",
> "$a="~i1,"$b=
> "ids));

Using a variadic function instead, and using format(), you could write it as

xchange(xmysql("UPDATE ",table," SET id2 = $a where id = $b ", "$a=",i1,"$b="ids));

Not quite the same, but better.

> I know that automatic conversion might be a bit confusing, but it adds so
> much
> to the readability of code.

That's mainly the reason.  The only "way" to do such a thing currently would be to have a String class, with overloaded opCat/opCatAssign operators for whatever types you wish to be automatically converted to strings.  Walter does _not_ really like implicit operations (like implicit casts, which is kind of what this is).

>Using a variadic function instead, and using format(), you could write it as
>
>xchange(xmysql("UPDATE ",table," SET id2 = $a where id = $b ", "$a=",i1,"$b="ids));

Well, it's not the same sadly.

I thinks I haveto write a code converter. It's sad that what Walter could do in
an hour, I will be doing maybe next few month. (Maybe Walter could add a
compiler switch instead. Ah, I am hoping to much.)
My work is very closly related to text handling and conversion is something I
need very often.

The other thing is if D want's to compete with PHP then it needs this conversion. For me is D a reasonable alterative to PHP when writing web.

Jarnet, thank you for answering me!

In article <das3lh$2k9g$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"M" <M_member@pathlink.com> wrote in message news:das2qq$2j5g$1@digitaldaemon.com...
>> but why not
>> xchange(xmysql("UPDATE "~table~" SET id2 = $a where id = $b ",
>> "$a="~i1,"$b=
>> "ids));
>
>Using a variadic function instead, and using format(), you could write it as
>
>xchange(xmysql("UPDATE ",table," SET id2 = $a where id = $b ", "$a=",i1,"$b="ids));
>
>Not quite the same, but better.
>
>> I know that automatic conversion might be a bit confusing, but it adds so
>> much
>> to the readability of code.
>
>That's mainly the reason.  The only "way" to do such a thing currently would be to have a String class, with overloaded opCat/opCatAssign operators for whatever types you wish to be automatically converted to strings.  Walter does _not_ really like implicit operations (like implicit casts, which is kind of what this is).
>
>

"M" <M_member@pathlink.com> wrote in message news:das2qq$2j5g$1@digitaldaemon.com...
> I am talking about automatic string conversion.
> Even Java has it!
>
> char []s;
> int n;
>
> why not?
> s=s~n;
>
> This is one thing that java is far better than D, I must sadly say.

Implicit conversions often make life easier and code simpler. Unfortunately, they also have a dark side. Too many of them wind up defeating static type checking, creating onerous and ugly bugs that manifest themselves only at runtime.

So it's a balancing act. Too few implicit conversions, and code is a pain to write. Too many, and it's a pain to debug.

Hi Walter,

I think implicit stringification of types would be one of those things in the "good" side of the balancing act. Not so the other way around, though. This mostly because of two things:

1) "Strings" have pretty much their own operator in D; you only have to watch out for that one thing. If the programmer does something like:

writef("Value=" ~ someInt);

I think it's pretty safe to assume he knows exactly what he's getting, in all situations. Whereas the reverse is not true, because all operators come into play.

int someInt = 42 + someString; // Ah! Watch out.
float someFloat = 3.14 * someString; // Watch out here too.
double someDouble = 6.66 / someString; // And here. Etc...

2) The second reason is that stringification is (or should be) an
exception-safe, error-free and very simple procedure.

// This is safe:
writef(toString(someInt));
// This not so much:
int someInt = toInt(someString);

Here's a simple, orthogonal solution to the problem:

Define a toString property for all types, just like .max. This is needed only for primitives, since I believe all objects already have it. Then, when implicit conversion to string is needed, the variable's toString is called.

Very simple, no surprising results, and no potential errors. toString should in theory never fail. This would be a _really_ great feature. I currently have tons of unsightly toString() calls all over the place. Plus there's the whole toString collision problem with std.date and co.

Thanks,
--AJG.



In article <dasvio$b5g$1@digitaldaemon.com>, Walter says...
>
>
>"M" <M_member@pathlink.com> wrote in message news:das2qq$2j5g$1@digitaldaemon.com...
>> I am talking about automatic string conversion.
>> Even Java has it!
>>
>> char []s;
>> int n;
>>
>> why not?
>> s=s~n;
>>
>> This is one thing that java is far better than D, I must sadly say.
>
>Implicit conversions often make life easier and code simpler. Unfortunately, they also have a dark side. Too many of them wind up defeating static type checking, creating onerous and ugly bugs that manifest themselves only at runtime.
>
>So it's a balancing act. Too few implicit conversions, and code is a pain to write. Too many, and it's a pain to debug.
>
>

Hi Walter,
What you think if there where a ~: operator or something other like that

char []a;
int n;
a=a~:n;

or if you wish
a=""~:n;

better than
a=a~toString(n);

a=toString(n);

+ you won't have this toString collation when you write classes.

What you think?

In article <dat2fp$e61$1@digitaldaemon.com>, AJG says...
>
>Hi Walter,
>
>I think implicit stringification of types would be one of those things in the "good" side of the balancing act. Not so the other way around, though. This mostly because of two things:
>
>1) "Strings" have pretty much their own operator in D; you only have to watch out for that one thing. If the programmer does something like:
>
>writef("Value=" ~ someInt);
>
>I think it's pretty safe to assume he knows exactly what he's getting, in all situations. Whereas the reverse is not true, because all operators come into play.
>
>int someInt = 42 + someString; // Ah! Watch out.
>float someFloat = 3.14 * someString; // Watch out here too.
>double someDouble = 6.66 / someString; // And here. Etc...
>
>2) The second reason is that stringification is (or should be) an
>exception-safe, error-free and very simple procedure.
>
>// This is safe:
>writef(toString(someInt));
>// This not so much:
>int someInt = toInt(someString);
>
>Here's a simple, orthogonal solution to the problem:
>
>Define a toString property for all types, just like .max. This is needed only for primitives, since I believe all objects already have it. Then, when implicit conversion to string is needed, the variable's toString is called.
>
>Very simple, no surprising results, and no potential errors. toString should in theory never fail. This would be a _really_ great feature. I currently have tons of unsightly toString() calls all over the place. Plus there's the whole toString collision problem with std.date and co.
>
>Thanks,
>--AJG.
>
>
>
>In article <dasvio$b5g$1@digitaldaemon.com>, Walter says...
>>
>>
>>"M" <M_member@pathlink.com> wrote in message news:das2qq$2j5g$1@digitaldaemon.com...
>>> I am talking about automatic string conversion.
>>> Even Java has it!
>>>
>>> char []s;
>>> int n;
>>>
>>> why not?
>>> s=s~n;
>>>
>>> This is one thing that java is far better than D, I must sadly say.
>>
>>Implicit conversions often make life easier and code simpler. Unfortunately, they also have a dark side. Too many of them wind up defeating static type checking, creating onerous and ugly bugs that manifest themselves only at runtime.
>>
>>So it's a balancing act. Too few implicit conversions, and code is a pain to write. Too many, and it's a pain to debug.
>>
>>
>
>

I think You should give developers freedom to chose what they like - if they want to write code that is hard to debug - let them do it - it is their problem anyway.

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

Dejan Lekic wrote:
> I think You should give developers freedom to chose what they like - if they
> want to write code that is hard to debug - let them do it - it is their
> problem anyway.

No, it's the maintenance engineer's problem :)

"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:dathls$vsq$1@digitaldaemon.com...
> I think You should give developers freedom to chose what they like - if
they
> want to write code that is hard to debug - let them do it - it is their problem anyway.

The problem with that is that implicit conversions will always be on, and one can inadvertently fall into the hole.

I agree with Walter regarding the balance of possibilities and constraints.

There is a big difference between these two things:
1.) Automatic conversion from integer to string in every cases.
2.) Give the possibility to the programmers to write easy string concatenation.

The first thing is very BAD for people who want to write reliable (not to difficult to write, easy to read, easy to debug) code.

The second thing is a NEED for all programmer to write code quickly with the consequences like debugging issues.

If anybody want to use "autoconverting" string class then one can write a simple
class with some overloaded operators. That's all, the resulting code could be so
short as it was in the first post. The possibility is here.
But we (at least I) do not want such MicroSoft (or Sun) like automagic thing.

Tamás Nagy


In article <daud1v$1qp9$1@digitaldaemon.com>, Walter says...
>
>"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:dathls$vsq$1@digitaldaemon.com...
>> I think You should give developers freedom to chose what they like - if
>they
>> want to write code that is hard to debug - let them do it - it is their problem anyway.
>
>The problem with that is that implicit conversions will always be on, and one can inadvertently fall into the hole.