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 Fri, 27 Nov 2009 04:49:00 GMT
So, what you're concerned with is the first parameter (the "thing" we
want to check, which we do so by reflection)?  Why do we need to
change its type?

On Thu, Nov 26, 2009 at 10:42 PM, Paul Benedict <pbenedict@apache.org> wrote:
> 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<pbenedict@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
>>> <james@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<pbenedict@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
>>>>> <james@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<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
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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