I understand that.  My point is that if you can create two, overloaded
methods (which I've shown you can do), one with one single argument
and one with var-args, then you can avoid the Object[] instantiation
in the single-argument case.

On Thu, Nov 26, 2009 at 9:42 PM, Paul Benedict <pbened...@apache.org> wrote:
> James,
>
> The compiler instantiates the Object[] every time because that's how
> the ellipsis notation is translated.
>
> Paul
>
> On Thu, Nov 26, 2009 at 7:38 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> Yes, but if the check passes, there's no need to create the Object[]
>> for single-argument method invocations.
>>
>> On Thu, Nov 26, 2009 at 10:59 AM, Paul Benedict <pbened...@apache.org> wrote:
>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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

Reply via email to