www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP9 -- Redo toString API

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
I just created a new D Improvement Proposal to fix the toString problem I  
brought up several posts ago.

See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

-Steve
Nov 18 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I just created a new D Improvement Proposal to fix the toString problem I  
 brought up several posts ago.

Thank you for writing the DIP. It looks interesting. I suggest to add an example, the implementation of toString() and writeTo() for a simple struct like this (or a class), so it's easy to compare them (code untested): struct Pair(T1, T2) { T1 first; T2 second; string toString() { return format("Pair(%s, %s)", first, second); } void writeTo(scope void delegate(in char[] data) sink, string format="") const { // code here... } } Bye, bearophile
Nov 18 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 18, 2010 14:21:20 Steven Schveighoffer wrote:
 I just created a new D Improvement Proposal to fix the toString problem I
 brought up several posts ago.
 
 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

Looks good overall, but I would point out that the text claims that sink is const scope - i.e. in - but the signature that's given is only scope. I assume that you intended to make the signature use in (or an explicit const scope) instead? - Jonathan M Davis
Nov 18 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer wrote:

 I just created a new D Improvement Proposal to fix the toString problem
 I brought up several posts ago.
 
 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

I think it's best to leave out the '%' from the format string, like Don has done with BigInt. This will facilitate the use of positional parameters, in which the percent is followed by a position specifier which necessarily has to be handled at a higher level than writeTo/ toString. Example: writefln("%2$s, %1$s!", "World", "Hello"); It's not clear from the DIP whether this is what you intended, so I think it should be specified. Other than that, I think this proposal looks solid. What's cool about this, apart from the performance benefits, is that it allows custom format specifiers to be used in a seamless manner. It would be even more powerful with Tango-like format specifiers, i.e. "{...}", but I guess that ship sailed a long time ago. ("%{...}s" could be an alternative, though.) -Lars
Nov 18 2010
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-11-18 23:21, Steven Schveighoffer wrote:
 I just created a new D Improvement Proposal to fix the toString problem
 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

 -Steve

Why do we have to remove toString, can't toString call writeTo and behave as it does now? -- /Jacob Carlborg
Nov 19 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 19 Nov 2010 10:22:29 +0100, Jacob Carlborg wrote:

 On 2010-11-18 23:21, Steven Schveighoffer wrote:
 I just created a new D Improvement Proposal to fix the toString problem
 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

 -Steve

Why do we have to remove toString, can't toString call writeTo and behave as it does now?

Nobody's forcing anyone to remove toString(), the point is that Phobos just won't be using it anymore. Furthermore, std.conv.to!string() should be defined to call writeTo(), so you won't have to define both toString() and writeTo() for your types. -Lars
Nov 19 2010
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 19-nov-10, at 10:22, Jacob Carlborg wrote:

 On 2010-11-18 23:21, Steven Schveighoffer wrote:
 I just created a new D Improvement Proposal to fix the toString  
 problem
 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

 -Steve

Why do we have to remove toString, can't toString call writeTo and behave as it does now?

that is what I do in blip. toString by default is char[] toString(){ return collectAppender(&desc); } I called the method desc because I saw it as description of the object. and if the object implements serialization then the description if just a serialization to json format (both of those are added by mixin printOut!();
Nov 19 2010
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 19-nov-10, at 11:13, Lars T. Kyllingstad wrote:

 On Fri, 19 Nov 2010 10:22:29 +0100, Jacob Carlborg wrote:

 On 2010-11-18 23:21, Steven Schveighoffer wrote:
 I just created a new D Improvement Proposal to fix the toString  
 problem
 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

 -Steve

Why do we have to remove toString, can't toString call writeTo and behave as it does now?

Nobody's forcing anyone to remove toString(), the point is that Phobos just won't be using it anymore. Furthermore, std.conv.to!string() should be defined to call writeTo(), so you won't have to define both toString() and writeTo() for your types. -Lars

I think that it is a good, a breaking change, but good. having something like what I did with writeOut would minimize the hassles, because then you have a uniform way to print out a type: writeOut(sink,type,possiblyExtraArgs) that works for everything, basic types, old style objects with toString,... it is useful for generic code.
Nov 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 18 Nov 2010 20:18:19 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, November 18, 2010 14:21:20 Steven Schveighoffer wrote:
 I just created a new D Improvement Proposal to fix the toString problem  
 I
 brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

Looks good overall, but I would point out that the text claims that sink is const scope - i.e. in - but the signature that's given is only scope. I assume that you intended to make the signature use in (or an explicit const scope) instead?

I looked at it again, I see 'in' there, is there something I'm missing? Reiterating here: void writeTo(scope void delegate(>>> in <<< char[] data) sink, string format = null) const -Steve
Nov 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 19 Nov 2010 02:27:07 -0500, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:

 On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer wrote:

 I just created a new D Improvement Proposal to fix the toString problem
 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

I think it's best to leave out the '%' from the format string, like Don has done with BigInt. This will facilitate the use of positional parameters, in which the percent is followed by a position specifier which necessarily has to be handled at a higher level than writeTo/ toString. Example: writefln("%2$s, %1$s!", "World", "Hello"); It's not clear from the DIP whether this is what you intended, so I think it should be specified.

Yes, I was not clear on what is passed in via format specifier. It should be more clear, will fix.
 Other than that, I think this proposal looks solid.  What's cool about
 this, apart from the performance benefits, is that it allows custom
 format specifiers to be used in a seamless manner.  It would be even more
 powerful with Tango-like format specifiers, i.e. "{...}", but I guess
 that ship sailed a long time ago.  ("%{...}s" could be an alternative,
 though.)

I think it leaves room for improvement, all that is necessary is to change the grammar for format specifiers to allow some kind of bracketing, and then we can have as much custom specifier as necessary. I didn't want to pretend I was good at tweaking format grammar specs, so I left it out :) All I said was that the format specifiers should follow the rules for standard format specifiers. -Steve
Nov 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 18 Nov 2010 17:43:51 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:

 I just created a new D Improvement Proposal to fix the toString problem  
 I
 brought up several posts ago.

Thank you for writing the DIP. It looks interesting. I suggest to add an example, the implementation of toString() and writeTo() for a simple struct like this (or a class), so it's easy to compare them (code untested): struct Pair(T1, T2) { T1 first; T2 second; string toString() { return format("Pair(%s, %s)", first, second); } void writeTo(scope void delegate(in char[] data) sink, string format="") const { // code here... } }

Will do. -Steve
Nov 19 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 I just created a new D Improvement Proposal to fix the toString problem  
 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

I've made suggested changes, please review again. Thanks -Steve
Nov 19 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I've made suggested changes, please review again.

Good, thank you. Just a note: a DIP is a public document so it's better to encourage good idioms inside it. "null" to represent empty arrays/strings is a bad practice, so instead of this: void writeTo(scope delegate(in char[] data) sink, string format = null) const { formattedWrite(sink, "(%s, %s)", first, second); } I suggest you to write something like: void writeTo(scope delegate(in char[] data) sink, string format="") const { formattedWrite(sink, "(%s, %s)", first, second); } More info about it: http://d.puremagic.com/issues/show_bug.cgi?id=3889 Bye, bearophile
Nov 19 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 Who said setting an array to null is bad practice?  I disagree.  null is a  
 better way to represent it, because it sets both the ptr and the length to  
 0, while "" only sets the length to 0.
 
 char[] arr = "";
 
 assert(arr == null); // passes
 assert(arr is null); // fails

I see, I didn't know this. Bye, bearophile
Nov 19 2010
prev sibling parent Pillsy <pillsbury gmail.com> writes:
Steven Schveighoffer Wrote:

 On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 I just created a new D Improvement Proposal to fix the toString 
 problem I brought up several posts ago.


 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9


 I've made suggested changes, please review again.

I like this design. Thanks for proposing it. Cheers, Pillsy
Nov 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 19 Nov 2010 09:14:07 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:

 I've made suggested changes, please review again.

Good, thank you. Just a note: a DIP is a public document so it's better to encourage good idioms inside it. "null" to represent empty arrays/strings is a bad practice, so instead of this: void writeTo(scope delegate(in char[] data) sink, string format = null) const { formattedWrite(sink, "(%s, %s)", first, second); } I suggest you to write something like: void writeTo(scope delegate(in char[] data) sink, string format="") const { formattedWrite(sink, "(%s, %s)", first, second); }

Who said setting an array to null is bad practice? I disagree. null is a better way to represent it, because it sets both the ptr and the length to 0, while "" only sets the length to 0. char[] arr = ""; assert(arr == null); // passes assert(arr is null); // fails I'd rather use a value that also allows code like: if(format is null) { // default to decimal format = "d"; } -Steve
Nov 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 19 Nov 2010 09:30:11 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:

 Who said setting an array to null is bad practice?  I disagree.  null  
 is a
 better way to represent it, because it sets both the ptr and the length  
 to
 0, while "" only sets the length to 0.

 char[] arr = "";

 assert(arr == null); // passes
 assert(arr is null); // fails

I see, I didn't know this.

BTW, the default value is not part of the function signature, if you want to in your code use = "", as long as you do the comparison correct, it should be valid. -Steve
Nov 19 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 19, 2010 05:54:15 Steven Schveighoffer wrote:
 On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer
 
 <schveiguy yahoo.com> wrote:
 I just created a new D Improvement Proposal to fix the toString problem
 I brought up several posts ago.
 
 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

I've made suggested changes, please review again. Thanks

The difference between the text and the function signature still exists (the text says that sink is const scope whereas the signature just says scope), though now the example (which I don't think was there before) is another place where just scope is used, so if the text is right and the actual function signature is wrong (as opposed to the other way around), then there are two places that need to be fixed. - Jonathan M Davis
Nov 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 19 Nov 2010 12:51:29 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Friday, November 19, 2010 05:54:15 Steven Schveighoffer wrote:
 On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer

 <schveiguy yahoo.com> wrote:
 I just created a new D Improvement Proposal to fix the toString  

 I brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

I've made suggested changes, please review again. Thanks

The difference between the text and the function signature still exists (the text says that sink is const scope whereas the signature just says scope),

Maybe you are confusing sink with sink's parameter, which is marked 'in'? I reworded the text to make it clearer. -Steve
Nov 19 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 19, 2010 10:26:40 Steven Schveighoffer wrote:
 On Fri, 19 Nov 2010 12:51:29 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 On Friday, November 19, 2010 05:54:15 Steven Schveighoffer wrote:
 On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer
 
 <schveiguy yahoo.com> wrote:
 I just created a new D Improvement Proposal to fix the toString

problem
 I brought up several posts ago.
 
 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

I've made suggested changes, please review again. Thanks

The difference between the text and the function signature still exists (the text says that sink is const scope whereas the signature just says scope),

Maybe you are confusing sink with sink's parameter, which is marked 'in'? I reworded the text to make it clearer.

The way I read it was that the delegate was supposed to be scope const, so if that's not the case, the original text wasn't clear enough, bu it's definitely clearer now. - Jonathan M Davis
Nov 19 2010
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On Thu, 18 Nov 2010 17:21:20 -0500
"Steven Schveighoffer" <schveiguy yahoo.com> wrote:

=20
 I just created a new D Improvement Proposal to fix the toString problem I=

 brought up several posts ago.
=20
 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

Hello, [Sorry for a partly personal message, but I cannot help it. At first sight,= my gut reaction in front of this proposal has been: no, nooo, NOOO!!! I wa= ited a few days because, _surely_, I was missing or misinterpreting some ba= sic point. But after several days and reads of the DIP, I still feel the sa= me and nobody seems to address the issue; so here I go. Excuse the noise if= I'm simply wrong. I feel ashamed to send that -- but let's be bold :-).] What I do not want is tostring be deprecated in any case. The proposal woul= d be OK if it introduced an _alternative_ for the cases (?) where string ou= tput efficiency is relevant. The language could/should default to writeTo i= s toString is not defined, *and* conversely default to toString if writeTo = is not defined. But in no way let down toString. Below quote of the DIP's r= elevant part. It is also, certainly, a very good idea to allow passing formatting data de= fault textual expression routines; but I fail to see why deprecating tostri= ng is necessary for that. Instead, it would certainly be a highly useful to= String parameter in numerous cases. I consider time & space efficiency for string output to be irrelevant, not = even a theoretic question. Maybe I simply have never reached points where i= t would? Have you ever stepped on a app not running correctly because toStr= ing allocates on the heap? Or is it random thoughts? First, as the proposal states, "Debug output is a common need when testing = code or logging data." Most uses of such tools are for programmer own feedb= ack -- user interface requires far more sophisticated, and in most case cus= tom, tools. Who cares how much memory or time is required? Memory is eventu= ally freed ayway, and output speed is not limited on the program side, but = well by rendering computations and/or physical limits (try to write to buff= er vs file vs terminal). Moreover, string output tasks often come last in a process chain -- that's = what a programmer waits for to get useful information on program behaviour = and be able to control, diagnose, compare... But the key point is that language features like D's toString are far to be= used only for _direct_ string output. They are extremely useful for numero= us tasks of string manipulation and processing, most of which again for pro= grammer's own use. Sometimes, at the end of process chain comes string otup= ut -- but indirectly. I have used languages in which there is no builtin support for an equivalen= t of toString, or not both for builtin and custom types. instead, one could= only writeTo, precisely. This is just pain (for me) at every corner of dev= elopper experience, from discovering the language to app maintenance, via e= xplorative development. Note there is no way to implement it by custom rout= ines in a typical static language, because it requires a high level of refl= exion; all builtin types must have it _and_ one must be able to explore the= complete description of custom types. My language of choice would be Oberon if only it included the strict minima= l programmer comfort toolkit, namely toString and a true builtin textual ty= pe. I let it down a few month ago *only* because of that -- it is a wonder= fully designed language in all other aspects, integrating the core needs fo= r modern programming in a few pages of spec -- it was simply no fun, consta= ntly. I want XXIth century programmming! ;-) [These news make me sad because I soon started to like D the language, even= its present chaotic pass, and its community as well.] Denis << The compiler will change its requirement for toString on structs. Curren= tly, if a struct defines toString, a function pointer to that function is p= laced in the {TypeInfo Struct}? member xtoString for that struct type. Sinc= e toString is no longer used, it should instead populate a new {TypeInfo St= ruct}? member xwriteTo function pointer with appropriate signature. As a path for deprecation, the compiler should populate both xtoString and = xwriteTo as defined in the struct. The runtime should use xwriteTo if defin= ed, and xtoString if not. After an appropriate time period (6 months?) the = compiler should print a message when toString is defined and writeTo is not= . Then after another appropriate time period, the compiler/runtime should s= top using toString and member xtoString altogether. Along the same lines, the default Object.writeTo should simply call toStrin= g and output the result to the sink. After an initial wait period, toString= should be deprecated, and after a transition period, toString should be re= moved, and the default writeTo should perform a similar action that the def= ault toString does now (print the object type name). Note that a cast will = be required in order for the const writeTo function to call the non-const t= oString. >> -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 21 2010
next sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 11/21/2010 11:10 AM, spir wrote:
 What I do not want is tostring be deprecated in any case. The proposal would
be OK if it introduced an _alternative_ for the cases (?) where string output
efficiency is relevant. The language could/should default to writeTo is
toString is not defined, *and* conversely default to toString if writeTo is not
defined. But in no way let down toString. Below quote of the DIP's relevant
part.
 It is also, certainly, a very good idea to allow passing formatting data
default textual expression routines; but I fail to see why deprecating tostring
is necessary for that. Instead, it would certainly be a highly useful toString
parameter in numerous cases.

Instead of return "something"; write sink("something"); You lose nothing. You do, however, gain the ability to output an object without concatenating a string over and over.
 I consider time&  space efficiency for string output to be irrelevant, not
even a theoretic question. Maybe I simply have never reached points where it
would? Have you ever stepped on a app not running correctly because toString
allocates on the heap? Or is it random thoughts?
 First, as the proposal states, "Debug output is a common need when testing
code or logging data." Most uses of such tools are for programmer own feedback
-- user interface requires far more sophisticated, and in most case custom,
tools. Who cares how much memory or time is required? Memory is eventually
freed ayway, and output speed is not limited on the program side, but well by
rendering computations and/or physical limits (try to write to buffer vs file
vs terminal).
 Moreover, string output tasks often come last in a process chain -- that's
what a programmer waits for to get useful information on program behaviour and
be able to control, diagnose, compare...

 But the key point is that language features like D's toString are far to be
used only for _direct_ string output. They are extremely useful for numerous
tasks of string manipulation and processing, most of which again for
programmer's own use. Sometimes, at the end of process chain comes string
otuput -- but indirectly.

With this, it doesn't need to be. Instead of writing another function for non-debuglike string output, just use writeTo.
Nov 21 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 11/21/2010 03:17 PM, spir wrote:
 No, just use toString. As said above, I don't want to writeTo, I want the
string; and be free to do whatever I want to with it. Being only able to write
is... (rather censure).

I... don't think you understand what writeTo is supposed to do. Inside to!string, it would be something like this: string s; arg.writeTo((const(char)[] data) { s ~= data; }); return s; There, you got the string. It will even be in a function for you, so you'll never have to write that piece of code. If you ever need the string of an object, you just write to!string(obj). No functionality lost, ever, at all. However, writeln can do this: foreach (arg; args) { arg.writeTo((const(char)[] data) { outputbuffer.put(data); }) } thereby removing the need to store the string, and the extra allocations. This design is much cleaner than the current strategy, and also more flexible.
Nov 21 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-21 17:28, Pelle Månsson wrote:
 On 11/21/2010 03:17 PM, spir wrote:
 No, just use toString. As said above, I don't want to writeTo, I want
 the string; and be free to do whatever I want to with it. Being only
 able to write is... (rather censure).

I... don't think you understand what writeTo is supposed to do. Inside to!string, it would be something like this: string s; arg.writeTo((const(char)[] data) { s ~= data; }); return s;

Why can't toString do the same ?
 There, you got the string. It will even be in a function for you, so
 you'll never have to write that piece of code. If you ever need the
 string of an object, you just write to!string(obj). No functionality
 lost, ever, at all.

 However, writeln can do this:

 foreach (arg; args) {
 arg.writeTo((const(char)[] data) { outputbuffer.put(data); })
 }

 thereby removing the need to store the string, and the extra allocations.

 This design is much cleaner than the current strategy, and also more
 flexible.

-- /Jacob Carlborg
Nov 21 2010
parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 11/21/2010 09:37 PM, Jacob Carlborg wrote:
 Inside to!string, it would be something like this:

 string s;
 arg.writeTo((const(char)[] data) { s ~= data; });
 return s;

Why can't toString do the same ?

Because then you'd have to write it? I'm afraid I don't understand.
Nov 21 2010
prev sibling next sibling parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 11/21/2010 09:49 PM, spir wrote:
 (Sorry for the irony.) "Make simple things easy." Have to write a delegate to
get feedback... to print a bit of text.
 (What is "hello, world!" in D?)

Missing the point, are we? Hello world is unchanged.
Nov 21 2010
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Nov 22, 10 04:49, spir wrote:
 On Sun, 21 Nov 2010 17:28:09 +0100
 Pelle Månsson<pelle.mansson gmail.com>  wrote:

 However, writeln can do this:

       foreach (arg; args) {
           arg.writeTo((const(char)[] data) { outputbuffer.put(data); })
       }

 thereby removing the need to store the string, and the extra allocations.

 This design is much cleaner than the current strategy, and also more
 flexible.

(Sorry for the irony.) "Make simple things easy." Have to write a delegate to get feedback... to print a bit of text. (What is "hello, world!" in D?) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com

Can't detect irony, captain. *You* don't need to write a delegate to get the string. That lower-level facility should have been packed up in the standard library function to!string which you don't need to care. All you need is to call the simple and easy function to!string(x) 1000 times if you want to waste 1000 memory allocations to get 1000 copy of strings.
Nov 21 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

spir wrote:
 On Sun, 21 Nov 2010 17:28:09 +0100
 Pelle M=C3=A5nsson <pelle.mansson gmail.com> wrote:
=20
 However, writeln can do this:

      foreach (arg; args) {
          arg.writeTo((const(char)[] data) { outputbuffer.put(data); })=


      }

 thereby removing the need to store the string, and the extra allocatio=


 This design is much cleaner than the current strategy, and also more=20
 flexible.

(Sorry for the irony.) "Make simple things easy." Have to write a deleg=

 (What is "hello, world!" in D?)
=20

will write "to!string (x)" instead of "x.toString()" How is that less easy? Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 21 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-21 05:10:13 -0500, spir <denis.spir gmail.com> said:

 I consider time & space efficiency for string output to be irrelevant, not
 even a theoretic question. Maybe I simply have never reached points where i
 t would? Have you ever stepped on a app not running correctly because toStr
 ing allocates on the heap? Or is it random thoughts?
 
 First, as the proposal states, "Debug output is a common need when testing
 code or logging data." Most uses of such tools are for programmer own feedb
 ack -- user interface requires far more sophisticated, and in most case cus
 tom, tools. Who cares how much memory or time is required? Memory is eventu
 ally freed ayway, and output speed is not limited on the program side, but
 well by rendering computations and/or physical limits (try to write to buff
 er vs file vs terminal).

I felt like that at first too. I like the simplicity of toString and though that perhaps both writeTo and toString should be allowed to coexist peacefully. But then I came to this realization: toString is almost like a language feature. And as a very visible idiom, it should set the example. If you show people toString functions with a signature that force needless allocations, they're going to reproduce the pattern for other things where they shouldn't. I think toString, or rather writeTo, should be a showcase of good practice, and thus I'm in favor of deprecating toString to increase exposure to the better idiom. Is this going to startle some people? Probably. But then perhaps they'll take a closer look and understand the design has its advantages and reuse it elsewhere. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 21 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 21 November 2010 02:10:13 spir wrote:
 On Thu, 18 Nov 2010 17:21:20 -0500
 
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote:
 I just created a new D Improvement Proposal to fix the toString problem I
 brought up several posts ago.
 
 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

Hello, [Sorry for a partly personal message, but I cannot help it. At first sight, my gut reaction in front of this proposal has been: no, nooo, NOOO!!! I waited a few days because, _surely_, I was missing or misinterpreting some basic point. But after several days and reads of the DIP, I still feel the same and nobody seems to address the issue; so here I go. Excuse the noise if I'm simply wrong. I feel ashamed to send that -- but let's be bold :-).]

You're not really losing toString(). to!string() would use writeTo() to convert objects to strings. writeln() and writefln() would use writeTo() to convert objects to strings (with the added benefit of potentially being able to use format specifiers other than %s - such as %d and %x for BigInt). format() would do the same. You're not losing _anything_ out of the deal except that you wouldn't do obj.toString(). Instead you'd do to!string(obj). The _only_ downside to it that I see is that it's going to be offputting to people to see writeTo()'s signature in comparison to toString(), and people will initially not understand how to just get a string like you currently would with toString() (similarly to your reaction). Once you understand how to using writeTo() to get a string, it should be quite easy and straightforward and not a problem at all. The end result will be more flexible and efficient, just potentially offputting until you understand how to use it. - Jonathan M Davis
Nov 21 2010
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On Sun, 21 Nov 2010 03:17:57 -0800
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 You're not losing _anything_ out of the deal except that you wouldn't do=

 obj.toString(). Instead you'd do to!string(obj).

I'm usually not using toString(), it's supported by the language. What abou= t format("%s:%s", a,b)? Will it still call toString implicitely, or writeTo= a buffer, or what else? Anyway, I cannot see any advantage in deprecating toString() for every prog= rammer in every use case, just for hypothetical efficiency issues -- that h= ave not yet been shown in concrete cases: an app that cannot work fine beca= use of toString allocating on the heap. Let us free to use our favorite too= ls, please! Do not pretend & telling us what is best for us. The solution is simple: toString() defaults to writeTo, writeTo defaults to= toString. This also solves 2 "human" issue you evoke: that people are used= to toString and know it very well, and that writeTo looks more intimidatin= g. As said in previous post, enhancing toString with a format specifier would = be cool. Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 21 2010
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 21.11.2010 17:08, spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis<jmdavisProg gmx.com>  wrote:

 You're not losing _anything_ out of the deal except that you wouldn't do
 obj.toString(). Instead you'd do to!string(obj).


may use whatever it wishes inside, as long as the net result is the same.
 Anyway, I cannot see any advantage in deprecating toString() for every
programmer in every use case, just for hypothetical efficiency issues -- that
have not yet been shown in concrete cases: an app that cannot work fine because
of toString allocating on the heap. Let us free to use our favorite tools,
please! Do not pretend&  telling us what is best for us.

apps just got a slight overall speed up in text I/O ? The only thing is to change the overridden method in your classes/structs, and besides your favorite toString is going to be supported for sometime. And allocating string on heap *is* an impact on performance when you want to print custom collections (and mind you, they can be quite long) in human-readable form.
 The solution is simple: toString() defaults to writeTo, writeTo defaults to
toString. This also solves 2 "human" issue you evoke: that people are used to
toString and know it very well, and that writeTo looks more intimidating.

 As said in previous post, enhancing toString with a format specifier would be
cool.

 Denis
 -- -- -- -- -- -- --
 vit esse estrany ☣

 spir.wikidot.com

-- Dmitry Olshansky
Nov 21 2010
prev sibling parent reply Don <nospam nospam.com> writes:
spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 
 You're not losing _anything_ out of the deal except that you wouldn't do 
 obj.toString(). Instead you'd do to!string(obj).

I'm usually not using toString(), it's supported by the language. What about format("%s:%s", a,b)? Will it still call toString implicitely, or writeTo a buffer, or what else? Anyway, I cannot see any advantage in deprecating toString() for every programmer in every use case, just for hypothetical efficiency issues

The efficiency issues are important, but are not the primary motivation. toString() is just wrong. The idea that there is ONE AND ONLY ONE textual representation of an object, is, frankly, idiotic.
Nov 21 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 The efficiency issues are important, but are not the primary motivation.
 toString() is just wrong. The idea that there is ONE AND ONLY ONE 
 textual representation of an object, is, frankly, idiotic.

To solve that the toString() may take an argument, like a formatting string or an enum, given to it by the to!() and writef(). (But I understand the idea with the sink is more efficient). Bye, bearophile
Nov 21 2010
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

spir wrote:
 On Sun, 21 Nov 2010 18:21:48 +0100
 Don <nospam nospam.com> wrote:
=20
 spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 You're not losing _anything_ out of the deal except that you wouldn'=




 obj.toString(). Instead you'd do to!string(obj).




writeTo a buffer, or what else?
 Anyway, I cannot see any advantage in deprecating toString() for ever=



 The efficiency issues are important,

1. Please bring concrete cases of apps that do not work well because of=

Please bring a concrete example of code that would suffer from the proposal. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 21 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 1. Please bring concrete cases of apps that do not work well because of
toString and would work fine just by replacing it with writeTo.

writeln is already slow. To print quickly numerical genomic data in D I have had to use printf in some situations.
 4. If you want another default and builtin tool, why not have both?

Because having two ways to do something makes the language more complex.
 But, yes, you are right and we all have been wrong for 20 years: toString is
junk. Thank you for this sudden enlightenment.

Progress happens :-) Bye, bearophile
Nov 21 2010
prev sibling next sibling parent Don <nospam nospam.com> writes:
spir wrote:
 On Sun, 21 Nov 2010 18:21:48 +0100
 Don <nospam nospam.com> wrote:
 
 spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 You're not losing _anything_ out of the deal except that you wouldn't do 
 obj.toString(). Instead you'd do to!string(obj).

Anyway, I cannot see any advantage in deprecating toString() for every programmer in every use case, just for hypothetical efficiency issues


1. Please bring concrete cases of apps that do not work well because of toString and would work fine just by replacing it with writeTo.

std.complex. A 3D vector. In fact, anything that involves floating point. Performance-wise, anything with a large array. Anything that calculates lazily. Etc.
 2. That a given %age of apps suffer of it is not enough reason for privating
other of their favorite tool, esp one that is anchored in everyday practice
 3. Is anyone forced to use toString? 

Yes. It's built into the type info of every struct.
 Man, this is simply not fair.

What do you think you will lose?
Nov 21 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Tomek Sowiski wrote:
 Don <nospam nospam.com> napisa(a):
 
 The efficiency issues are important, but are not the primary motivation.
 toString() is just wrong. The idea that there is ONE AND ONLY ONE 
 textual representation of an object, is, frankly, idiotic.

I always thought of toString() as an aid in debugging, where having one and only way to print out an object makes sense.

It isn't just used in debugging. It's used for writefln. But even for debugging, it doesn't work. If I have a struct: struct Foo { Complex!(double) val; } and, for debugging purposes, I want to write 'val' to 10 decimal places. How do I do that?
 But strong words 
 suggest you see something I don't. What problems does offering choice 
 solve? How and to whom would I pass my choice?

Creating a wrapper for the simple case is trivial, once you have the more general case. The simple case doesn't need to integrated into the compiler and runtime at all. (Nor does the general case, actually, a fact which is not recognized in the DIP). I think it's actually a hack from the days before the language had templates.
Nov 22 2010
parent Don <nospam nospam.com> writes:
spir wrote:
 On Mon, 22 Nov 2010 10:14:03 +0100
 Don <nospam nospam.com> wrote:
 
 Tomek Sowiński wrote:
 Don <nospam nospam.com> napisał(a):

 The efficiency issues are important, but are not the primary motivation.
 toString() is just wrong. The idea that there is ONE AND ONLY ONE 
 textual representation of an object, is, frankly, idiotic.

and only way to print out an object makes sense.

But even for debugging, it doesn't work. If I have a struct: struct Foo { Complex!(double) val; } and, for debugging purposes, I want to write 'val' to 10 decimal places. How do I do that?

I agree with you. toString lacks flexibility in some (not very common but relevant) cases, that would be brought by an optional format specifier. I would enjoy beeing able to write this with toString, instead of a custom text() method: struct Complex { float r,i; string text(string numberFormat="%.3f") { string outFormat = format("%s+%sj", numberFormat,numberFormat); return format(outFormat, this.r,this.i); } } void main () { auto c = Complex(1.11111,3.333333333); writeln(c.text()); writeln(c.text("%.7f")); } ==> 1.111+3.333j 1.1111100+3.3333333j But, to be fair, does this have anything to do with the current <writeTo vs toString> debate? The only actual point of said debate is efficiency.

The debate was triggered by me saying (in Bugzilla) that BigInt would not provide a parameterless toString(), because I can't implement it. Instead, in BigInt, I provided a function: void toString( void delegate(const(char)[]) sink, string format); which solves the formatting issue, as well as the performance issue. I'm certainly open to other ways of solving the problem. But string toString(); doesn't seem adequate for the task.
Nov 22 2010
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
spir schrieb:
 toString is so wrong that it's often the first method most users of most
 OO language implement -- to ensure vivious bugs won't pass unseen -- to
 be able to combine representations into more complete representations--
 to construct useful feedback about their app in general.
 When a type has only 2 methods thet're the constructor and toString.

So? In the future the first implemented method will be writeTo(). Sure, "void writeTo(scope void delegate(in char[] data) sink, string format) const" looks more intimidating than "string toString()", but once you've seen an example how this is to be implemented (like struct Pair from the DIP) that's not a problem anymore. "formattedWrite(sink, "blahfoo %s", foo);" is as easy as "return format("blahfoo %s", foo);" Isn't it? Cheers, - Daniel
Nov 22 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/11/2010 17:21, Don wrote:
 spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 You're not losing _anything_ out of the deal except that you wouldn't
 do obj.toString(). Instead you'd do to!string(obj).

I'm usually not using toString(), it's supported by the language. What about format("%s:%s", a,b)? Will it still call toString implicitely, or writeTo a buffer, or what else? Anyway, I cannot see any advantage in deprecating toString() for every programmer in every use case, just for hypothetical efficiency issues

The efficiency issues are important, but are not the primary motivation. toString() is just wrong. The idea that there is ONE AND ONLY ONE textual representation of an object, is, frankly, idiotic.

That idea is quite idiotic indeed, no question about it. However, that is not toString() 's idea! The point of toString (at least across languages, not D specifically) is to provide a *default* representation of a type. It doesn't preclude other representations, and if format&friends (writef, etc.), don't provide an integrated way to create/write a string using custom formats for a given object/struct, that is format's problem, it is not toString's fault. One might ask, well, is toString any use then? Yes, very much, the idea to provide a *default* representation of an object/struct is quite useful. There are many situations where one would want to print a string of an object without specifying any particular format. In fact, there are some situations where specifying a particular format would not even be possible or make sense, for example, when the code doesn't know the exact type of the underlying object/struct (and thus not know what formats are supported). Like a container printing its elements. Another example I take from Java, it doesn't apply that much to D (at least not at the moment), but still I want to point it out: toString() is used extensively by the integrated debugger in JDT to print representations of objects in views, popups, etc.. In fact, I think that coding only a default toString for a type may be more common than otherwise (coding a toString that actually uses the format specifiers). The string based format specifier is just not that common outside of numerical types. The question remains, if toString should support a format specifier or not. I think it shouldn't, if there is an alternative satisfactorily solution for numerical types and format&friends. -- Bruno Medeiros - Software Engineer
Dec 02 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 02/12/2010 21:08, Steven Schveighoffer wrote:
 On Thu, 02 Dec 2010 11:31:49 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 21/11/2010 17:21, Don wrote:

 That idea is quite idiotic indeed, no question about it. However, that
 is not toString() 's idea! The point of toString (at least across
 languages, not D specifically) is to provide a *default*
 representation of a type.

 It doesn't preclude other representations, and if format&friends
 (writef, etc.), don't provide an integrated way to create/write a
 string using custom formats for a given object/struct, that is
 format's problem, it is not toString's fault.

to!string(x) will handle what toString does now.

So? What was the point here, I didn't get it.
 In fact, I think that coding only a default toString for a type may be
 more common than otherwise (coding a toString that actually uses the
 format specifiers). The string based format specifier is just not that
 common outside of numerical types.

You can ignore the format specifier if you want to. -Steve

For calling toString, yes, you can ignore it. But as for defining the toString method, not entirely, you still have to write the format parameter (", string format = null"). After that it won't hinder you in any way, it will just be unnecessary visual baggage. So the downside of having to write that extra parameter is incredibly low, it is merely aesthetic (plus the initial one-off impact of people learning what the format parameter is for). However, toString is a core part of the language, and a very common to define, and if D were to gain more mainstream usage, I worry that something like 98% (or something like that) of all toStrings would not use format, so it seems like a bit of a waste. It is not an issue I care that much about, only a little bit. -- Bruno Medeiros - Software Engineer
Dec 07 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 07/12/2010 17:31, Steven Schveighoffer wrote:
 On Tue, 07 Dec 2010 11:44:56 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 02/12/2010 21:08, Steven Schveighoffer wrote:
 On Thu, 02 Dec 2010 11:31:49 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 21/11/2010 17:21, Don wrote:

 That idea is quite idiotic indeed, no question about it. However, that
 is not toString() 's idea! The point of toString (at least across
 languages, not D specifically) is to provide a *default*
 representation of a type.

 It doesn't preclude other representations, and if format&friends
 (writef, etc.), don't provide an integrated way to create/write a
 string using custom formats for a given object/struct, that is
 format's problem, it is not toString's fault.

to!string(x) will handle what toString does now.

So? What was the point here, I didn't get it.

The point is, we don't need a toString method *and* a formatted output method. The toString method is replaced by the formatted output method in the proposal (writeTo), which already contains a format specifier.
 In fact, I think that coding only a default toString for a type may be
 more common than otherwise (coding a toString that actually uses the
 format specifiers). The string based format specifier is just not that
 common outside of numerical types.

You can ignore the format specifier if you want to. -Steve

For calling toString, yes, you can ignore it. But as for defining the toString method, not entirely, you still have to write the format parameter (", string format = null"). After that it won't hinder you in any way, it will just be unnecessary visual baggage.

Yes, that is my point.
 So the downside of having to write that extra parameter is incredibly
 low, it is merely aesthetic (plus the initial one-off impact of people
 learning what the format parameter is for).
 However, toString is a core part of the language, and a very common to
 define, and if D were to gain more mainstream usage, I worry that
 something like 98% (or something like that) of all toStrings would not
 use format, so it seems like a bit of a waste.

 It is not an issue I care that much about, only a little bit.

In the proposal, toString is removed, only writeTo would exist (which has formatting support). I guess I don't really understand what you are asking for. I interpreted your posts as requests that we don't change/deprecate toString, is that not the case? -Steve

No, that wasn't the case at all. Looking back, it's partially my fault I wasn't clear on that. I was disagreeing with Don's "The idea that there is ONE AND ONLY ONE textual representation of an object, is, frankly, idiotic" , but it wasn't to support spir's argument "I cannot see any advantage in deprecating toString()". I'm fine with D's current toString to be removed/deprecated, or made into a final method that calls writeTo (slightly prefer last alternative). Also, I kept mentioning "toString" and not "writeTo" in my posts because I started by talking generically of the string-representation mechanism across languages, not about D specifically. Actually, this brings me to another beef I have with the proposal (kinda bikeshed, but still a bit significant): the new "writeTo" method should have string somewhere in the name. So, like "writeString", or "writeStringTo", or something like that. If it's about strings, it should have string in the signature. Even more so because "writeTo" is a very generic name, it might cause a bit of confusion with socket or serialization kinds of classes. -- Bruno Medeiros - Software Engineer
Dec 14 2010
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On Sun, 21 Nov 2010 15:55:10 +0100
Pelle M=C3=A5nsson <pelle.mansson gmail.com> wrote:

 But the key point is that language features like D's toString are far t=


merous tasks of string manipulation and processing, most of which again for= programmer's own use. Sometimes, at the end of process chain comes string = otuput -- but indirectly. =20
=20
 With this, it doesn't need to be. Instead of writing another function=20
 for non-debuglike string output, just use writeTo.

No, just use toString. As said above, I don't want to writeTo, I want the s= tring; and be free to do whatever I want to with it. Being only able to wri= te is... (rather censure). Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 21 2010
parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.532.1290349037.21107.digitalmars-d puremagic.com...
On Sun, 21 Nov 2010 15:55:10 +0100
Pelle Mnsson <pelle.mansson gmail.com> wrote:

 But the key point is that language features like D's toString are far 
 to be used only for _direct_ string output. They are extremely useful 
 for numerous tasks of string manipulation and processing, most of which 
 again for programmer's own use. Sometimes, at the end of process chain 
 comes string otuput -- but indirectly.

With this, it doesn't need to be. Instead of writing another function for non-debuglike string output, just use writeTo.

No, just use toString. As said above, I don't want to writeTo, I want the string; and be free to do whatever I want to with it. Being only able to write is... (rather censure).

If you just want the string, then just use to!string(x), or format("%s", x), or anything else that implicity converts types to strings. I don't understand what the problem is.
Nov 21 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Sun, 21 Nov 2010 18:21:48 +0100
Don <nospam nospam.com> wrote:

 spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
=20
 You're not losing _anything_ out of the deal except that you wouldn't =



 obj.toString(). Instead you'd do to!string(obj).

I'm usually not using toString(), it's supported by the language. What =


teTo a buffer, or what else?
=20
 Anyway, I cannot see any advantage in deprecating toString() for every =


=20
 The efficiency issues are important,

1. Please bring concrete cases of apps that do not work well because of toS= tring and would work fine just by replacing it with writeTo.=20 2. That a given %age of apps suffer of it is not enough reason for privatin= g other of their favorite tool, esp one that is anchored in everyday practi= ce. 3. Is anyone forced to use toString? Why don't people who refuse toString u= se any other tool they like better? Some argue that we don't lose anything.= .. the same applies for you. 4. If you want another default and builtin tool, why not have both? 5. 99% of "hand-made" string construction & output happen at the end of a p= rocess, before waiting for user input, or other situations where efficiency= is no more that blank word. Man, this is simply not fair.
 but are not the primary motivation.
 toString() is just wrong. The idea that there is ONE AND ONLY ONE=20
 textual representation of an object, is, frankly, idiotic.

Who argues for "ONE AND ONLY ONE textual representation"? And how does writ= eTo allow better textual diversity, anyway (aside passing format specs, whi= ch could as well fit toString)? Where is the argument? toString is so wrong that it's often the first method most users of most OO= language implement -- to ensure vivious bugs won't pass unseen -- to be ab= le to combine representations into more complete representations-- to const= ruct useful feedback about their app in general. When a type has only 2 met= hods thet're the constructor and toString. But, yes, you are right and we a= ll have been wrong for 20 years: toString is junk. Thank you for this sudde= n enlightenment. (Aside this point, I guess we all are used to build various textual represe= ntations of all kinds of objects, for various uses. The one provided by toS= tring beeing special in that it is implicitely invoked by some very handy t= ools like %s. So handy that I ) denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 21 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Sun, 21 Nov 2010 17:28:09 +0100
Pelle M=C3=A5nsson <pelle.mansson gmail.com> wrote:

 However, writeln can do this:
=20
      foreach (arg; args) {
          arg.writeTo((const(char)[] data) { outputbuffer.put(data); })
      }
=20
 thereby removing the need to store the string, and the extra allocations.
=20
 This design is much cleaner than the current strategy, and also more=20
 flexible.

(Sorry for the irony.) "Make simple things easy." Have to write a delegate = to get feedback... to print a bit of text. (What is "hello, world!" in D?) Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 21 2010
prev sibling next sibling parent =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
Don <nospam nospam.com> napisa=B3(a):

 The efficiency issues are important, but are not the primary motivatio=

 toString() is just wrong. The idea that there is ONE AND ONLY ONE  =

 textual representation of an object, is, frankly, idiotic.

I always thought of toString() as an aid in debugging, where having one = = and only way to print out an object makes sense. But strong words sugges= t = you see something I don't. What problems does offering choice solve? How= = and to whom would I pass my choice? -- = Tomek
Nov 21 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 10:14:03 +0100
Don <nospam nospam.com> wrote:

 Tomek Sowi=C5=84ski wrote:
 Don <nospam nospam.com> napisa=C5=82(a):
=20
 The efficiency issues are important, but are not the primary motivatio=



 toString() is just wrong. The idea that there is ONE AND ONLY ONE=20
 textual representation of an object, is, frankly, idiotic.

I always thought of toString() as an aid in debugging, where having one=


 and only way to print out an object makes sense.=20

It isn't just used in debugging. It's used for writefln. But even for debugging, it doesn't work. =20 If I have a struct: =20 struct Foo { Complex!(double) val; } =20 and, for debugging purposes, I want to write 'val' to 10 decimal places. How do I do that?

I agree with you. toString lacks flexibility in some (not very common but r= elevant) cases, that would be brought by an optional format specifier. I wo= uld enjoy beeing able to write this with toString, instead of a custom text= () method: struct Complex { float r,i; string text(string numberFormat=3D"%.3f") { string outFormat =3D format("%s+%sj", numberFormat,numberFormat); return format(outFormat, this.r,this.i); } } void main () { auto c =3D Complex(1.11111,3.333333333); writeln(c.text()); writeln(c.text("%.7f")); } =3D=3D> 1.111+3.333j 1.1111100+3.3333333j But, to be fair, does this have anything to do with the current <writeTo vs= toString> debate? The only actual point of said debate is efficiency. Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 22 2010
prev sibling next sibling parent so <so so.do> writes:
 toString lacks flexibility in some (not very common but relevant) cases.

That pretty much says that you don't do much of math coding/debugging. It is very common on the other side of the world. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 22 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 21 Nov 2010 05:10:13 -0500, spir <denis.spir gmail.com> wrote:

 On Thu, 18 Nov 2010 17:21:20 -0500
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 I just created a new D Improvement Proposal to fix the toString problem  
 I
 brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

Hello, [Sorry for a partly personal message, but I cannot help it. At first sight, my gut reaction in front of this proposal has been: no, nooo, NOOO!!! I waited a few days because, _surely_, I was missing or misinterpreting some basic point. But after several days and reads of the DIP, I still feel the same and nobody seems to address the issue; so here I go. Excuse the noise if I'm simply wrong. I feel ashamed to send that -- but let's be bold :-).]

Thanks for the input, but you are missing several very important points: 1. toString will not be made 'illegal', you can still write toString methods and use them as you wish (writing a toString method without also writing a writeTo method will be deprecated for a time, but after that the compiler will not complain). But writeln, format, to!string, etc. will not use them. 2. toString can unequivocally be replaced anywhere you see it with to!string. There is zero loss of functionality, and the change is not unpleasant. Not only that, but almost *no* code uses toString, it is more correct to use to!string, and let to!string make the right decision. The reason is because to!string handles builtin types (which have no toString member), and custom structs without a toString member. You should never have to write a delegate to pass to writeTo directly unless you have some funky way of outputting the data, but in that case, writeTo is better for you anyways. 3. Yes, toString could support an optional formatting argument, but that is not my main concern (it is Don's and others, I'm assuming you too). My main concern is that in order to hook into writeln, format, to!string, etc, your type *must* define a function that necessarily allocates memory. writeTo not only solves that problem, but in most cases does not change the difficulty of converting objects/structs to text format (and in many cases, it simplifies the code which creates the string). -Steve
Nov 22 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 11:02:48 -0500
"Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 On Sun, 21 Nov 2010 05:10:13 -0500, spir <denis.spir gmail.com> wrote:
=20
 On Thu, 18 Nov 2010 17:21:20 -0500
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 I just created a new D Improvement Proposal to fix the toString proble=



 I
 brought up several posts ago.

 See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9

Hello, [Sorry for a partly personal message, but I cannot help it. At first =20 sight, my gut reaction in front of this proposal has been: no, nooo, =20 NOOO!!! I waited a few days because, _surely_, I was missing or =20 misinterpreting some basic point. But after several days and reads of =


 the DIP, I still feel the same and nobody seems to address the issue; s=


 here I go. Excuse the noise if I'm simply wrong. I feel ashamed to send=


 that -- but let's be bold :-).]

Thanks for the input, but you are missing several very important points: =20 1. toString will not be made 'illegal', you can still write toString =20 methods and use them as you wish (writing a toString method without also =

 writing a writeTo method will be deprecated for a time, but after that th=

 compiler will not complain).  But writeln, format, to!string, etc. will =

 not use them.
 2. toString can unequivocally be replaced anywhere you see it with =20
 to!string.  There is zero loss of functionality, and the change is not =20
 unpleasant.  Not only that, but almost *no* code uses toString, it is mor=

 correct to use to!string, and let to!string make the right decision.  The=

 reason is because to!string handles builtin types (which have no toString=

 member), and custom structs without a toString member.  You should never =

 have to write a delegate to pass to writeTo directly unless you have some=

 funky way of outputting the data, but in that case, writeTo is better for=

 you anyways.
 3. Yes, toString could support an optional formatting argument, but that =

 is not my main concern (it is Don's and others, I'm assuming you too).  M=

 main concern is that in order to hook into writeln, format, to!string, =20
 etc, your type *must* define a function that necessarily allocates =20
 memory.  writeTo not only solves that problem, but in most cases does not=

 change the difficulty of converting objects/structs to text format (and i=

 many cases, it simplifies the code which creates the string).
=20
 -Steve

Right, thank you for the answer. Let us stop this discusson (I will) and wa= it for real trial when an implementation is available. Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Nov 22 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 02 Dec 2010 11:31:49 -0500, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 21/11/2010 17:21, Don wrote:
 spir wrote:
 On Sun, 21 Nov 2010 03:17:57 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 You're not losing _anything_ out of the deal except that you wouldn't
 do obj.toString(). Instead you'd do to!string(obj).

I'm usually not using toString(), it's supported by the language. What about format("%s:%s", a,b)? Will it still call toString implicitely, or writeTo a buffer, or what else? Anyway, I cannot see any advantage in deprecating toString() for every programmer in every use case, just for hypothetical efficiency issues

The efficiency issues are important, but are not the primary motivation. toString() is just wrong. The idea that there is ONE AND ONLY ONE textual representation of an object, is, frankly, idiotic.

That idea is quite idiotic indeed, no question about it. However, that is not toString() 's idea! The point of toString (at least across languages, not D specifically) is to provide a *default* representation of a type. It doesn't preclude other representations, and if format&friends (writef, etc.), don't provide an integrated way to create/write a string using custom formats for a given object/struct, that is format's problem, it is not toString's fault.

to!string(x) will handle what toString does now.
 In fact, I think that coding only a default toString for a type may be  
 more common than otherwise (coding a toString that actually uses the  
 format specifiers). The string based format specifier is just not that  
 common outside of numerical types.

You can ignore the format specifier if you want to. -Steve
Dec 02 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 07 Dec 2010 11:44:56 -0500, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 02/12/2010 21:08, Steven Schveighoffer wrote:
 On Thu, 02 Dec 2010 11:31:49 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 21/11/2010 17:21, Don wrote:

 That idea is quite idiotic indeed, no question about it. However, that
 is not toString() 's idea! The point of toString (at least across
 languages, not D specifically) is to provide a *default*
 representation of a type.

 It doesn't preclude other representations, and if format&friends
 (writef, etc.), don't provide an integrated way to create/write a
 string using custom formats for a given object/struct, that is
 format's problem, it is not toString's fault.

to!string(x) will handle what toString does now.

So? What was the point here, I didn't get it.

The point is, we don't need a toString method *and* a formatted output method. The toString method is replaced by the formatted output method in the proposal (writeTo), which already contains a format specifier.
 In fact, I think that coding only a default toString for a type may be
 more common than otherwise (coding a toString that actually uses the
 format specifiers). The string based format specifier is just not that
 common outside of numerical types.

You can ignore the format specifier if you want to. -Steve

For calling toString, yes, you can ignore it. But as for defining the toString method, not entirely, you still have to write the format parameter (", string format = null"). After that it won't hinder you in any way, it will just be unnecessary visual baggage.

Yes, that is my point.
 So the downside of having to write that extra parameter is incredibly  
 low, it is merely aesthetic (plus the initial one-off impact of people  
 learning what the format parameter is for).
 However, toString is a core part of the language, and a very common to  
 define, and if D were to gain more mainstream usage, I worry that  
 something like 98% (or something like that) of all toStrings would not  
 use format, so it seems like a bit of a waste.

 It is not an issue I care that much about, only a little bit.

In the proposal, toString is removed, only writeTo would exist (which has formatting support). I guess I don't really understand what you are asking for. I interpreted your posts as requests that we don't change/deprecate toString, is that not the case? -Steve
Dec 07 2010