Alex Blewitt wrote: > IMNSHO I don't think we should by default copy the toString() > behaviour from the RI, unless mandated by the spec in JavaDoc. > Frankly, the toString() has always been undefined, and I'm sick off > Java developers saying "Well, yes, but I always expect it to be > [name='value',name='other value']" and then writing toString() methods > that do exactly the same. > > toString() was never meant to be a dump of the object's fields and > values. It was meant to be a string representation of the object. And > it's an insanely ineffecient measure to dump out all of an object's > fields using toString() anyway, because of all the wasted > concatenation that goes on when you have nested objects. > > It would be much better if Java developers on the whole got over the > fascination with toString() and its format, and used better mechanisms > for writing out debug state (e.g. dump(Writer) *) if they needed -- or > better yet, just used a debugger.
Ok. Good rant, and I agree with it, but I still don't see a reason here why we shouldn't, other than to .... teach people a lesson? geir > > Alex. > > * Why everyone wants to stream toString() values is beyond me. If you > just write the output to a stream in the first place, you get the > concatenation for free without having to do all that expensive memory > manipuation. > > On 06/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> Yep. No answer yet. I pinged them for an update, and also asked the >> toString() question. >> >> geir >> >> Mikhail Loenko wrote: >> > IIRC Geir was going to ask Sun if we are allowed to copy their >> > exception messages >> > >> > Thanks, >> > Mikhail >> > >> > 2006/7/5, Richard Liang <[EMAIL PROTECTED]>: >> >> >> >> >> >> Geir Magnusson Jr wrote: >> >> > Richard Liang wrote: >> >> > >> >> >> Geir Magnusson Jr wrote: >> >> >> >> >> >>> Tim Ellison wrote: >> >> >>> >> >> >>> >> >> >>>>> >> >> >>>>> >> >> >>>> Yep, if the spec tells you what the format of the string should >> >> be then >> >> >>>> follow it (since apps may be dependent upon it), otherwise I'd be >> >> >>>> inclined to invent your own useful string representation. >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>> This idea scares me. I think people do depend on toString() when >> >> >>> writing apps, and tend to shove that kind of thing to log files >> >> and such >> >> >>> on server apps. To have our outptut different from Sun's, BEA's, >> >> IBM's, >> >> >>> Apple's seens like we're asking for trouble. >> >> >>> >> >> >>> >> >> >>> >> >> >> Hello Geir, >> >> >> >> >> >> IMHO, as long as the method does not give confusing message to >> >> >> developers, we are not required to have the same behavior. You may >> >> want >> >> >> to refer to the spec of java.lang.Object.toString: >> >> >> ... >> >> >> In general, the toString method returns a string that "textually >> >> >> represents" this object. The result should be a concise but >> >> informative >> >> >> representation that is easy for **a person to read**. >> >> >> ... >> >> >> >> >> > >> >> > Sure, but that doesn't mean that it would be reasonable to randomly >> >> > change the output of a given Class's toString() as long as it >> would be >> >> > easy for a person to read :) >> >> > >> >> > I know that's not what you are advocating, and I certainly agree >> >> that no >> >> > one should depend on toString() output like that, but I also know >> that >> >> > in production systems *I* have done it, and I'm sure others have as >> >> well. >> >> > >> >> > >> >> >> And there are some cases that we even cannot follow RI. >> >> >> e.g., >> >> >> URLConnection conn = new >> >> URL("http://www.apache.org").openConnection(); >> >> >> System.out.println(conn.toString()); >> >> >> >> >> >> The code above will print >> >> >> "sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org" >> >> >> >> >> >> Any comments? Thanks a lot. >> >> >> >> >> > >> >> > Well, we could actually print that if that was our impl of >> >> URLConnection >> >> > for HTTP, but still, I think >> >> > >> >> > >> "org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org" >> >> > >> >> > would be more reasonable than >> >> > >> >> > "Implementing Class : org.apache.harmony.whatever.HttpURLConnection, >> >> > Target URI : http://www.apache.org" >> >> > >> >> > or something like that, even thought the second is perfectly good. >> >> > >> >> > All I'm saying is that unless the output from the RI's toString() is >> >> > particularly brain-dead, it doesn't seem to be too much of a >> bother to >> >> > be similar. >> >> > >> >> > >> >> Agree. And in fact, it's easier to have the same output as RI's if we >> >> are allowed. :-) Could we think this rule also apply to the message >> when >> >> an exception is thrown? >> >> >> >> Any comments? Thanks a lot. >> >> >> >> Best regards, >> >> Richard >> >> >> >> > Just my $0.02 >> >> > >> >> > geir >> >> > >> >> > >> >> >> Best regards, >> >> >> Richard >> >> >> >> >> >>> geir >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >> >>> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >>> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> >>> For additional commands, e-mail: >> >> [EMAIL PROTECTED] >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> > >> >> > >> --------------------------------------------------------------------- >> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> > >> >> > >> >> > >> >> >> >> -- >> >> Richard Liang >> >> China Software Development Lab, IBM >> >> >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]