harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [classlib] compatibility of toString
Date Thu, 06 Jul 2006 07:57:09 GMT
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.

On 06/07/06, Geir Magnusson Jr <geir@pobox.com> 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 <richard.liangyx@gmail.com>:
> >>
> >>
> >> 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: harmony-dev-unsubscribe@incubator.apache.org
> >> >>> For additional commands, e-mail:
> >> harmony-dev-help@incubator.apache.org
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >
> >> > ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> Richard Liang
> >> China Software Development Lab, IBM
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message