[jira] [Issue Comment Edited] (LANG-611) Consider improvements in LANG-396

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Issue Comment Edited] (LANG-611) Consider improvements in LANG-396

Sebb (Jira)

    [ https://issues.apache.org/jira/browse/LANG-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065722#comment-13065722 ]

Matt Benson edited comment on LANG-611 at 7/15/11 5:19 AM:
-----------------------------------------------------------

With my rejections removed:
{noformat}
        // 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);

        // Triple valued logic ala databases.

        // 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: feels okay
        boolean _CharRange_containsAll(char... values);
        boolean _CharRange_containsAny(char... 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: 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);

        //
        // ---------- 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

{noformat}

I will break these into subtasks.


      was (Author: mbenson):
    With my rejections removed:
{noformat}
        // 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);

        // Triple valued logic ala databases.

        // 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: feels okay
        boolean _CharRange_containsAll(char... values);
        boolean _CharRange_containsAny(char... 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: 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);

        //
        // ---------- 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

{noformat}

I will break these into additional requests.

 

> Consider improvements in LANG-396
> ---------------------------------
>
>                 Key: LANG-611
>                 URL: https://issues.apache.org/jira/browse/LANG-611
>             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: http://www.atlassian.com/software/jira