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.
>
> 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.
Here here; if only the API was printOn(OutputStream) then we'd all be
happy(er).
Regards,
Tim
> 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]
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
