commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [lang] next version etc
Date Sun, 16 Apr 2006 14:23:22 GMT
>>20015: WONTIFX? Gary's on making Entities public. Looks like a lump of
>>work to do, is it likely to happen or should we just decide that
>>Entities shouldn't be public? I don't recall user's being desperate to
>>use this class.
> Release early, release often. Let's leave this one for later.

-1.- XML at this level is out of scope

>>26659: WONTFIX? Seems like too much in the way of date work - suggest
>>JODA instead unless a patch is offered.
> I use Joda-Time now. I would even like to propose deprecating DateUtils
> 'softly' in favor of Joda-Time. I am sure many will not like this at all
> since Joda-Time is pretty large.

-1. There are many complications getting this kind of calculation right, 
and people should be forced to use a proper tool ;-)

>>29692: Patch recently added. Consider and either apply or WONTFIX.
> Seems too specific/complex.

-1. A multiline string isn't really the same as a regular string. Its 
more at the business logic level to define how a multiline string works 
(ie. perhaps it should be a class holding a String[])

>>30082: WONTFIX. This is too specific an issue to be putting in Lang I
> believe.
> I agree.

Much of StringEscapeUtils is dubious scope for lang. Adding this doesn't 

>>30184: Consider for lang.text.
> There are no unit tests provided (I know, the class is pretty simple). 

Could be added, though I'm not especially fussed.

>>31602: Sean/Stephen, thoughts? Should we WONTFIX as too complicated,
>>or is it simple enough and we can do it?

-1, This stalled because its a mess of possible issues. There isn't even 
a solution in Joda-Time yet.

>>33102: FIX: On the one hand, it's pretty simple stuff, and we'd have
>>to support the roll(..) method. On the other hand, user's like this
>>stuff and it's not hard to add it, even if we overload with Calendar
>>as well. 4 methods would be needed.
> +0. Joda-Time?

+1 to add, -0 to roll.

>>33401: FIX: it's a bit redundant, but I've no reason not to have these
>>methods available. Any -1s?
> Needs better method names IMO. -0. I'm always in favor of release early,
> release often when there are no unit tests with a code proposal ;)

-1, these seem too specific to me

>>33609: FIX. Javadoc needs improving.
> Nothing wrong with better docs! :)


>>33825: WONTFIX. Standard java.time question - is it valuable and
>>simple, or should we just point to JODA? I'm going to go with WONTFIX
>>as my default answer on time enhancements.
> I'm with you: Joda-Time.

-1. The JDK doesn't support time or date ranges. Trying to patch support 
in would lead to large amounts of code in the end.

>>33889: Unsure. Could be a CharSet enhancement instead of just a camel
>>case method. Thoughts?

+1. But stick with a fairly simple implementation.

>>33997: I think this is a useful method - just need to make sure the
>>implementation is the best possible.
> What about commons-math?

Trouble is that double can't accurately hold some numeric values. I 
believe that this is what BigDecimal is for. I won't stop a 
mathematician having a go though.

>>34284: FIX: NullPointer; test and fix.

+1 FIX

>>34351: FIX: I don't see any reason not to try to write Albert's
>>method. If not obvious when digging into it, then we can WONTFIX.

Not something I've ever hit, but no objections to FIX.

>>35400: WONTFIX. I'm -1 to a new classloader in lang, starts to leave
>>the scope of 'simple' to my ignorant brain :)

Probably should fix this, but classloaders just go wrong. -1

>>35588: Part of the lang.text call.
> I need text.VariableFormatter. If 2.2 does not come out soon, I am going
> to pluck it out of there for our own use ;)

Do you need all its complexity with escaping?

>>35826: Bring up with [math]. I think it could be in either, not sure I
>>have the itch to write a BigXxx replacement though.
> Indeed, what does [math] think about that? It would be interesting to
> know what the [math] folks think about project boundaries for class like
> that.

There is almost certainly a need for these classes, but I'm not 
volunteering to write them from scratch.

>>36061: FIX. Seems simple enough - bug and patches.
> Some of these bugs might be obsolete. I thought I'd take care of object
> cycles a while back. Hm, but that might have been for the
> ReflectionToStringBuilder class, not the ToStringBuilder.

FIX if still an issue

>>36512: FIX. I think there's value for a .forName improvement.
> Personally, I would only do the super simple stuff, primitives I
> suppose. Arrays of primitives ok... Basically, anything that you can say
> in Java code: "int", "int[]". Yeah, that's nice. But I would not want to
> have us invent a mini-language which the talk of eating up spaces starts
> to feel like. My vote would be to keep it simple in the first cut, if it
> is there at all.

+1, but treat this with care. Its a potential feature scope into parsing 
the whole of Java.

>>36666: Thoughts? Is it worth putting that inside the Enum code?
> It would be nice to be Java 5/6 friendly.

Needs a bit of investigation. Fix if possible.

>>36873: FIX: Hooked to lang.text; but as a patch is provided I don't
>>see any reason not to go with that.

I dislike the subclass implementation. Also the general scope of 
VariableFormatter keeps growing from a simple string substituter.

>>36886: FIX: Seems valid. Tied to 2.2 vs 3.0 I think - backwards
> compat.

Change on v3.0

>>36915: WONTFIX: As I've no idea what's actually being said :)

>>36925: Status Gary?
> I like the feature and it is done and it tested. The only thing I can
> think of is trying to make the API names better (they seem fine now to
> me).

I would like to see method override taking in a Collection of Strings, 
otherwise its done.

>>37243: Time pain :) Thoughts?
> Does Joda-Time deal with this case?

This is a BUG and should be fixed.

>>37385: DOC. Don't see any problem in saying that apos; isn't included.
> Agreed, especially if the HTML spec is clear about it and we can point
> to it.


>>37499: WONTFIX. Point to JODA.
> +1.

FIX. If we provide a feature, then it should be done properly. This is a 
simple change, and should be made.

>>37690: FIX. Unit test offered.
> +1. I love when there's a unit test :)

Sounds like a BUG, so FIX.

>>38210: Thoughts? Is it undesired?
> I wonder if the XML spec has anything to say about that.

Not my area of expertise.

>>38401: Examine further. FIX if possible.

May be tricky to fix.

>>38569: FIX. Patch supplied - though might need improvement.

Sounds like a BUG, so FIX

>>38800: Consider. Either FIX or point to JODA.
> IMO: Point to Joda-Time for now.


>>38912: No clue or itch on this one. Is it important for us to provide
>>this? Is it of use to users, or just to other libraries who 50% of the
>>time don't have a dependency on lang?
> Dunno either. Seems nice. Is there an example where lang would eat its
> own dog food and use it internally?

Out of scope.

>>39254: Hesitant to offer up more lang.time functionality. Thoughts on
> this?

Sounds OK.

>>39315: Seems worthy of application.

Needs doing to match Reflection version.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message