commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <>
Subject [jira] [Commented] (LANG-611) Consider improvements in LANG-396
Date Fri, 15 Jul 2011 05:17:59 GMT


Matt Benson commented on LANG-611:

My feelings:
	// ---------- org.apache.commons.lang ----------

	// MJB: Extending every operation to handle arrays of arrays seems pointless;
	// having rejected that idea these are pretty easy to do using java.lang.reflect.Array:
	boolean _ArrayUtils_areSameLength(Object[]... arrays);
	boolean _ArrayUtils_areSameType(Object[]... arrays);

	// MJB: pending community accord, rejected in LANG-470:
	boolean _ArrayUtils_containsAnyOf(Object[] array, Object... possibleValues);
	boolean _ArrayUtils_containsAllOf(Object[] array, Object... possibleValues);

	// MJB: no varargs for the sake of varargs
	boolean _ArrayUtils_areEmpty(Object[]... arrays);
	Object[] _ArrayUtils_addAll(Object[]... arrays);
	Object[] _ArrayUtils_add(Object[] array, Object... values);

	// MJB: these would complement ArrayUtils.addAll(), but not so palatable X 8 primitive component
types.  Would rename removeAll and removeElements if accepted.
	Object[] _ArrayUtils_remove(Object[] array, int... indices);
	Object[] _ArrayUtils_removeElement(Object[] array, Object... values);

	// MJB: this seems to confuse BitField with java.util.BitSet, different purpose
	int _BitField_xor(int... field);
	int _BitField_or(int... field);
	int _BitField_and(int... field);
	int _BitField_nor(int... field);
	int _BitField_nand(int... field);

	// Triple valued logic ala databases.
	// MJB: we have this one:
	Boolean _BooleanUtils_xor(Boolean... bools);

	// MJB: probably reasonable to accept remaining:
	Boolean _BooleanUtils_or(Boolean... bools);
	Boolean _BooleanUtils_and(Boolean... bools);
	Boolean _BooleanUtils_nor(Boolean... bools);
	Boolean _BooleanUtils_nand(Boolean... bools);

	// MJB: no pointless varargs
	boolean _CharEncoding_areSupported(String... encodings);
	// MJB: feels okay
	boolean _CharRange_containsAll(char... values);
	boolean _CharRange_containsAny(char... values);

	// MJB: in MethodUtils, plus he forgot his ellipsis ;)
	java.lang.reflect.Method _ClassUtils_getPublicMethod(Class cls, String methodName, Class<?>

	// MJB: no pointless varargs
	boolean _ClassUtils_areSameClass(Class... clases);
	// MJB: done
	<T> T ObjectUtil_min (Comparable<T>... values);
	<T> T ObjectUtil_max (Comparable<T>... values);

	// MJB: hmm, PITA but could be useful for non-numeric types which are outside the purview
of [math] component
	<T> T ObjectUtil_mode(Comparable<T>... values);
	<T> T ObjectUtil_median(Comparable<T>... values);

	// MJB: no pointless varargs, but the method/parameter name combination is admittedly pretty
	<T> T ObjectUtil_areAllEqual(T... createdMen);

	// MJB: what's the use case for serializing a bunch of objects to one stream?
	void _SerializationUtils_serialize( outputStream,

	// MJB: doesn't really hurt anything, but not a huge priority--kind of breaks symmetry vs.
the signature with format elements:
	void _Validate_noNullElements(Object... collection);

	// MJB: done
	String _WordUtils_capitalize(String str, char... delimiters);
	String _WordUtils_capitalizeFully(String str, char... delimiters);
	String _WordUtils_initials(String str, char... delimiters);
	String _WordUtils_uncapitalize(String str, char... delimiters);

	// ---------- org.apache.commons.lang.builder ----------

	// MJB: done
	org.apache.commons.lang.builder.ReflectionToStringBuilder _ReflectionToStringBuilder_setExcludeFieldNames(String...

	// MJB: violates the principle of ToStringBuilder
	org.apache.commons.lang.builder.ToStringBuilder append(boolean... values);

	// ---------- org.apache.commons.lang.math ----------

	// MJB: these make sense:
	int _NumberUtils_min(int... values);
	int _NumberUtils_max(int... values);

	// MJB: pointless varargs, no; one method to get the overlap of two Ranges, yes
	org.apache.commons.lang.math.Range _Range_overlap(org.apache.commons.lang.math.Range... range);

	// ---------- org.apache.commons.lang.text ----------

	// Match according to the first Format which parses correctly.
	// e.g. allows dates as ddmmyy dd-mm-yyyy, etc.
	// MJB: reasonable
	void _CompositeFormat(java.text.Format formatter, java.text.Format... parsers); // constructor

	// ---------- org.apache.commons.lang.time ----------

	// MJB: no pointless varargs
	boolean _DateUtils_isSameDay(java.util.Calendar... cals);
	boolean _DateUtils_isSameDay(java.util.Date... dates);
	boolean _DateUtils_isSameInstant(java.util.Calendar... cals);
	boolean _DateUtils_isSameInstant(java.util.Date... date);
	boolean _DateUtils_isSameLocalTime(java.util.Calendar... cals);
	//MJB: assuming we take CompositeFormat with n parsers, no need:
	java.util.Date _DateUtils_parseDate(String str, String... parsePatterns);

> Consider improvements in LANG-396
> ---------------------------------
>                 Key: LANG-611
>                 URL:
>             Project: Commons Lang
>          Issue Type: Improvement
>          Components: General
>            Reporter: Henri Yandell
>             Fix For: 3.x
> Richard's patch in LANG-396 had various improvement suggestions in addition to vararg
fixing. Consider.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message