On Thu, 18 Nov 2010 17:21:20 -0500 "Steven Schveighoffer" <schvei...@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 :-).] 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. 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. I have used languages in which there is no builtin support for an equivalent 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 developper experience, from discovering the language to app maintenance, via explorative development. Note there is no way to implement it by custom routines in a typical static language, because it requires a high level of reflexion; 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 minimal programmer comfort toolkit, namely toString and a true builtin textual type. I let it down a few month ago *only* because of that -- it is a wonderfully designed language in all other aspects, integrating the core needs for modern programming in a few pages of spec -- it was simply no fun, constantly. 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. Currently, if a struct defines toString, a function pointer to that function is placed in the {TypeInfo Struct}? member xtoString for that struct type. Since toString is no longer used, it should instead populate a new {TypeInfo Struct}? 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 defined, 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 stop using toString and member xtoString altogether. Along the same lines, the default Object.writeTo should simply call toString and output the result to the sink. After an initial wait period, toString should be deprecated, and after a transition period, toString should be removed, and the default writeTo should perform a similar action that the default 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 toString. >> -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
