[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cp-patches] Fix For Bug #11545 -- Locale Regression
From: |
Michael Koch |
Subject: |
Re: [cp-patches] Fix For Bug #11545 -- Locale Regression |
Date: |
Tue, 11 Jan 2005 23:48:03 +0100 |
User-agent: |
KMail/1.7.1 |
Am Dienstag, 11. Januar 2005 23:20 schrieb Andrew John Hughes:
> On Tue, 2005-01-11 at 16:30, Jeroen Frijters wrote:
> > Andrew John Hughes wrote:
> > > I'm committing the following patch which fixes the
> > > NullPointerException being thrown.
> >
> > You didn't include the patch,
>
> Sorry, I wrote the mail and forgot to actually attach... :(
>
> > but I have a comment anyway ;-)
> >
> > Sun uses a magic currency "XXX" to solve this problem, please at
> > least consider taking this approach instead of inventing another
> > scheme. Tests for this behavior are already in Mauve.
> >
> > Thanks.
> >
> > Regards,
> > Jeroen
>
> Yes, I've seen this Mauve testcase (which, IIRC, now fails).
> Personally, I feel that copying obscure parts of Sun's
> implementation is not right for GNU Classpath. The above is not
> documented (AFAICS) in the specification, and only occurs in Sun's
> VM. In fact, the documentation for setCurrency() suggests that
> null is a perfectly valid value for the currency attribute. I
> haven't invented a new scheme, but followed the spec. (and common
> sense) as much as possible. getCurrency() returning null is a lot
> clearer than obscure "XXX" strings getting into your programs
> anyway, IMO. Generally, if you want the currency symbols, I would
> imagine you would ensure that they are available.
As long as there are no real world applications depending on the "XXX"
we should leave it like it is.
> This has already been discussed generally on a recent
> address@hidden thread about Mauve, where I believe it was noted
> that following obscure parts of Sun's implementation should be
> considered a buggy test.
I wouldn't consider this a buggy test. It just tests for unspecified
behavior. Some real world applications depend on unspecified
behaviors. Thats quiet common, unfortunately. Having a testcase for
this helps us to find out when SUN changes its behavior and when we
break the "unspecified" behavior.
Michael
--
Homepage: http://www.worldforge.org/