commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [lang 3] static or dynamic type checks?
Date Thu, 26 Nov 2009 13:11:02 GMT
I just wrote a class that included...

    public static <T> T someMethod(T val)
    {
        System.out.println("Single value method!");
        return val;
    }

    public static <T> T[] someMethod(T... values)
    {
        System.out.println("Multi-value method.");
        return values;
    }

    public static void main(String[] args)
    {
        someMethod("Hello");
        someMethod("Hello", "World");
    }

When I ran it, it printed:

Single value method!
Multi-value method.

So, what's the big deal?  Create a single-value method and create a
multi-value method.  I must be missing something in this discussion.

On Thu, Nov 26, 2009 at 12:16 AM, Paul Benedict <pbenedict@apache.org> wrote:
> If we want to implement LANG-508 (Validate: add message parameter
> construction via elllipsis notation to speed up processing), I am
> really concerned with the many overloaded versions of #validIndex()
> and #notEmpty() that solely differ by static argument type:
> Collection, Object, Object[], CharSequence, etc.
>
> Because var-args instantiate a new Object[], it won't be possible to
> easily create one-argument optimized overloaded versions to prevent
> the creation. Such as:
> public static <T> T[] notEmpty(Object array, String message, Object var1);
> public static <T> T[] notEmpty(Object array, String message, Object
> var1, Object var2);
> public static <T> T[] notEmpty(Object array, String message, Object
> var1, Object var2, Object var3);
> public static <T> T[] notEmpty(Object array, String message, Object
> var1, Object var2, Object var3, Object... vars);
>
> I am following the good advice on Joshua Bloch on this one. It's item
> #42 in his Effective Java book.
>
> I want to eliminate the overloaded versions by type and check those
> types using instanceof instead. Thoughts?
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message