On 07/07/06, Magnusson, Geir <[EMAIL PROTECTED]> wrote:
> If people are relying on one implementation that's undocumented
> behaviour, then it's bad code. It may well fail on any other system
> (inc. embedded systems, or other OS, or even between different
> versions).
No kidding. Welcome to t
> -Original Message-
> From: Alex Blewitt [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 07, 2006 11:52 AM
> To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
> Subject: Re: Re: [classlib] compatibility of toString
>
> On 06/07/06, Geir Magnusson Jr <
On 06/07/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Here here; if only the API was printOn(OutputStream) then we'd all be
happy(er).
I suspect that it's hear, hear, at least there (in Parliament). :-)
Alex.
-
Terms of use :
On 06/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
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.
Ok. Good rant, and I agree with it, but I still don't see a reason here
why we shouldn'
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
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='val
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 th
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 Magnus
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 tell
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 u
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 representati
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Andrew Zhang wrote:
On 7/1/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
On 01/07/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Agree. But there are always exceptions. Some "toString" methods have to
contain some key informatio
Tim Ellison wrote:
> Andrew Zhang wrote:
>> On 7/1/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
>>> On 01/07/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Agree. But there are always exceptions. Some "toString" methods have to
contain some key information as spec required, for example, the
Hello,
One special case: I'd suggest to test that if you specify some text as
an constructor argument to a subclass of Throwable, then toString()
contains that text.
On 7/3/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Andrew Zhang wrote:
> On 7/1/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
>>
>>
Andrew Zhang wrote:
> On 7/1/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
>>
>> On 01/07/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>> >
>> > Agree. But there are always exceptions. Some "toString" methods have to
>> > contain some key information as spec required, for example, the size or
>> > ind
On 7/1/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
On 01/07/06, Andrew Zhang <[EMAIL PROTECTED]> 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 t
On 01/07/06, Andrew Zhang <[EMAIL PROTECTED]> 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
On 7/1/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
I'd say that (like hashCode()) there's not a lot of point in testing
the exact output, only behaviour. In other words, if it returns a
String, that should be good enough. There's nothing in the spec to say
what it should be -- all of the toStrin
I'd say that (like hashCode()) there's not a lot of point in testing
the exact output, only behaviour. In other words, if it returns a
String, that should be good enough. There's nothing in the spec to say
what it should be -- all of the toString() methods could return
"Harmony is Great!" and it'd
Hi community!
While looking through some of java.beans tests I found many places
where exact output of toString() method is being tested. Moreover, the
test patterns differ from the output generated by RI's toString's.
IMHO there is no much sense in testing of toString() since normally
users do
20 matches
Mail list logo
