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 <pbened...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
