Fair enough.
What about APIs that change from, for example, String to CharSequence, should
these stay with the same @since tags, even if the Java version for the project
of the @since version did not include the class CharSequence.
Gary
> -Original Message-
> From: Henri Yandell [mai
I think it does.
The choice of a new package name was a workaround rather than a
declaration of a different package, so the @since's still have value.
Hen
On Sat, Mar 6, 2010 at 5:13 PM, Gary Gregory
wrote:
> Looking at trunk I see that the @since tags are still there. Since the
> package o.a.
On 03/03/2010, Niall Pemberton wrote:
> I have made a couple of more changes following Sebb's comments:
> - removed the deprecated parameter
> - moved the javadoc/source plugins MANIFEST config to the
> section:
>
> http://svn.apache.org/viewvc?view=revision&revision=918281
>
> I'll exten
Here is another issue that I find confusing at first glance with Generics. I
redefined defaultIfEmpty in my sandbox as follows:
public static T defaultIfEmpty(T str, T
defaultStr) {
return StringUtils.isEmpty(str) ? defaultStr : str;
}
This is simple enough but I was surprised
Here is another low hanging fruit:
public static int length(CharSequence str) {
return str == null ? 0 : str.length();
}
I committed that one since it is trivial and matches the is*(CharSequence)
methods already there.
Gary
> -Original Message-
> From: Henri Yandell [m
Looking at trunk I see that the @since tags are still there. Since the package
o.a.c.lang3 is new, does it make sense to have @since tags OTHER than 3.0 if
any?
Gary Gregory
Senior Software Engineer
Seagull Software
email: ggreg...@seagullsoftware.com
email: ggreg...@apache.org
www.seagullsoftwa
When I replaced the current implementation of StringUtils.left(String,int) with:
@SuppressWarnings("unchecked")
public static T left(T cs, int len) {
if (cs == null) {
return null;
}
if (len < 0) {
return (T) cs.subSequence(0, 0);
}
Hello.
> Here is one. The goal is to provide an over-dispersed exponential
> distribution which is defined as an exponential distribution with a prior
> distribution on the lambda parameter.
>
> /**
> * Sample from an exponential distribution whose parameter is distributed
> according
> * to a
Oops sorry, wrong list!
On 06/03/2010, sebb wrote:
> The votes are:
>
> +1
> Oleg (binding)
> Asankha (binding)
> Sebb (binding)
> Erik Hubert
>
> There were no other votes, so the vote passes.
>
> I'll upload the jars shortly.
>
>
> S///
>
---
On 06/03/2010, Henri Yandell wrote:
> I find this a tricky one.
>
> When it's explicitly referring to the type, CharSequence seems fine,
> but to change the text that is talking about what a method does to:
>
> "Work out a CharSequence's length"
>
> It feels very unwieldy.
>
> Do others find
I find this a tricky one.
When it's explicitly referring to the type, CharSequence seems fine,
but to change the text that is talking about what a method does to:
"Work out a CharSequence's length"
It feels very unwieldy.
Do others find this weird, or is it just me?
On Sat, Mar 6, 2010 at 2:28
The votes are:
+1
Oleg (binding)
Asankha (binding)
Sebb (binding)
Erik Hubert
There were no other votes, so the vote passes.
I'll upload the jars shortly.
S///
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For a
On 06/03/2010, ggreg...@apache.org wrote:
> Author: ggregory
> Date: Sat Mar 6 22:09:37 2010
> New Revision: 919859
>
> URL: http://svn.apache.org/viewvc?rev=919859&view=rev
> Log:
> Change length(String) to length(CharSequence)
>
> Modified:
>
> commons/proper/lang/trunk/src/main/java
Making these immutable will be a real pain as demonstrated by the
over-dispersed exponential example. In particular, to maintain performance,
it would require that all constructors be arranged to allow injection of a
random number generator. Management of that would be a nasty code issue.
Better
On 2010-03-06 01:15, sebb wrote:
> The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the
> next release should be 2.0 rather 1.5, as IO now requires Java 1.5,
> that requires a major version change.
+1
> Does that make sense?
> If so, then the maven id can also be fixed (see IO-12
Gilles Sadowski wrote:
> Hi.
>
>>> > I don't see any changes proposed.
>>>
>>>
>>> I propose to use the instance variable in place of the accessor.
>>>
>>>
>>> > I see a couple of statements that getters are used (usually considered
>>> > good), and a question about over-riding.
>>>
>>>
>>> Get
luc.maison...@free.fr wrote:
> - "Gilles Sadowski" a écrit :
>
>> Hello.
>>
>> I'm ready to make the changes proposed in
>> https://issues.apache.org/jira/browse/MATH-348
>
> Hi Gilles,
>
> Sorry, I forgot to comment on the issue. I agree with you, go ahead with the
> changes.
>
+0
So
Henri Yandell writes:
> Very close to 3.0. The major items remaining are:
>
> * LANG-396Investigate for vararg usages
>
> Lots left on this one - we've not really vararg'd the API yet.
If you're happy with the changes I proposed early in 2008, I'll
implement them in the next wee
18 matches
Mail list logo
