James,
Yes. I want to also eliminate the static types of all the overloaded
methods. We don't need a version for maps, one for char sets, one for
objects, one for collections, etc. We can do all those checks dynamically.
This was my point of my original email. What are your thoughts on it?
Paul
On 11/26/2009 8:50 PM, James Carman wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
