The purpose of var-args, at least from my vantage, is to produce
detail messages that are used by java.lang.String.format.
Paul
On Thu, Nov 26, 2009 at 7:11 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
