harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [classlib] compatibility of toString
Date Tue, 04 Jul 2006 02:00:43 GMT


Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>   
>> Andrew Zhang wrote:
>>     
>>> On 7/1/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
>>>       
>>>> On 01/07/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
>>>>         
>>>>> Agree. But there are always exceptions. Some "toString" methods have
to
>>>>> contain some key information as spec required, for example, the size
or
>>>>> index.
>>>>>           
>>>> Can you give examples of where the spec specifically mandates the
>>>> return values of either size or index?
>>>>         
>>> What I mean is in some cases, toString returns a string is not enough.
>>> e.g. "Harmony is Great"  obviously doesn't comply with spec
>>> AbstractCollection.toString() as you mentioned below.
>>> Another example is CharBuffer.toString(). The spec says:
>>> "Returns a string containing the characters in this buffer.
>>> The first character of the resulting string will be the character at this
>>> buffer's position, while the last character will be the character at index
>>> limit() - 1. Invoking this method does not change the buffer's position. "
>>>
>>> Therefore, for these special cases, tests for toString are useful. Of
>>> course, instead of comparing Harmony's toString return value with RI's, the
>>> test should verify whether Harmony's toString value complys with spec. The
>>> test should not look like:
>>> assertEquals(RI_TOSTRING, instance.toString());
>>> For CharBuffer.toString, the test may be written as following:
>>> assertEquals(the character at this bufer's position, the first character of
>>> toString);
>>> ....
>>>
>>> For most other cases, IMO, Harmony doesn't need to keep the same return
>>> value as RI's.
>>>
>>> Thanks!
>>>       
>> 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**.
...

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.

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
>
>
>   

-- 
Richard Liang
China Software Development Lab, IBM 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message