Not that I'm saying we *should* do either of these things but let's remember that most places where one formerly would have said "support collections" should now be substituted "support iterables".
Matt On Fri, Sep 20, 2013 at 9:25 AM, Benedikt Ritter <[email protected]>wrote: > Not sure if you're being sarcastic, but yes that would probably make sense. > > > 2013/9/20 James Carman <[email protected]> > > > If we're going to support varargs, we should also support collections. > > > > On Fri, Sep 20, 2013 at 10:11 AM, Benedikt Ritter <[email protected]> > > wrote: > > > I guess it's just convenience... > > > > > > if( StringUtils.isAnyBlank(str1, str2, str3)) > > > > > > is shorter than > > > > > > if( StringUtils.isBlank(str1) && StringUtils.isBlank(str2) && > > > StringUtils.isBlank(str3) ) > > > > > > Benedikt > > > > > > > > > 2013/9/20 James Carman <[email protected]> > > > > > >> What is the usecase for something like this? Are we more likely to > > >> have varargs params or a collection? Varargs *can* happen, but what > > >> is the more likely case? > > >> > > >> On Fri, Sep 20, 2013 at 9:30 AM, Benedikt Ritter <[email protected]> > > >> wrote: > > >> > Hi, > > >> > > > >> > we have this pull request on github [1] with an accompanying jira > > issue > > >> [2]. > > >> > I'd say it is a useful addition but I think I remember a > contribution > > of > > >> > noneIsNull(Object... args) for Validate, that we rejected. So I > > wanted to > > >> > be sure about our policy here: > > >> > > > >> > Do we want to add corresponding var args methods for boolean > isXXX(T) > > >> > methods that model AND and OR? > > >> > > > >> > Regards, > > >> > Benedikt > > >> > > > >> > [1] https://github.com/apache/commons-lang/pull/3 > > >> > [2] https://issues.apache.org/jira/browse/LANG-848 > > >> > > > >> > -- > > >> > http://people.apache.org/~britter/ > > >> > http://www.systemoutprintln.de/ > > >> > http://twitter.com/BenediktRitter > > >> > http://github.com/britter > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
