Re: [configuration2]: AbstractConfiguration::getArray

2016-05-02 Thread Jörg Schaible
Oliver Heger wrote:

> 
> 
> 
> Am 29.04.2016 um 20:36 schrieb Jörg Schaible:
>> c...@honton.org wrote:
>> 
>>> Jorge,
>>>
>>> You could create a different named method for each primitive array
>>> type.  Would be a pain to use in a generic fashion.
>> 
>> 
>> [snip]
>> 
>> I agree with a method returning explicitly an array, but that has been
>> nonsense in first place.
>> 
>> As I already pointed out, the existing
>> 
>>   T get(Class cls, String key);
>> 
>> would have been completely enough. See my examples from the last mail.
> 
> IIRC get() currently cannot handle arrays, but this should be easy to
> add. So could you please open a Jira ticket to track this?

Done: CONFIGURATION-626

Cheers,
Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-29 Thread Oliver Heger


Am 29.04.2016 um 20:36 schrieb Jörg Schaible:
> c...@honton.org wrote:
> 
>> Jorge,
>>
>> You could create a different named method for each primitive array
>> type.  Would be a pain to use in a generic fashion.
> 
> 
> [snip]
> 
> I agree with a method returning explicitly an array, but that has been 
> nonsense in first place.
> 
> As I already pointed out, the existing
> 
>   T get(Class cls, String key);
> 
> would have been completely enough. See my examples from the last mail.

IIRC get() currently cannot handle arrays, but this should be easy to
add. So could you please open a Jira ticket to track this?

Thanks
Oliver

> 
> Cheers,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-29 Thread Jörg Schaible
c...@honton.org wrote:

> Jorge,
> 
> You could create a different named method for each primitive array
> type.  Would be a pain to use in a generic fashion.


[snip]

I agree with a method returning explicitly an array, but that has been 
nonsense in first place.

As I already pointed out, the existing

  T get(Class cls, String key);

would have been completely enough. See my examples from the last mail.

Cheers,
Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-29 Thread chas

Jorge,

You could create a different named method for each primitive array  
type.  Would be a pain to use in a generic fashion.


Play with the following sample code to see why the return type
needs to be Object.

regards,
chas



import java.lang.reflect.Array;
import java.lang.reflect.Field;

import org.junit.Test;

public class GenericCastTest {

@SuppressWarnings("unchecked")
public  T[] newEmptyArray(Class cls) {
return (T[]) Array.newInstance(cls, 0);
}

/**
 * Can't overload method because type erasure is same
 */
public int[] newEmptyIntArray(Class cls, String key) {
return (int[]) Array.newInstance(cls, 0);
}

public static class ConfigPojo {
public int[] intParam;
}

@Test(expected=ClassCastException.class)
public void useObjectReturn() throws IllegalArgumentException,  
IllegalAccessException {

// won't compile
// int[] empty = newEmptyArray(Integer.TYPE);

ConfigPojo cp = new ConfigPojo();
fillWithEmptyArrays(cp);
}

private void fillWithEmptyArrays(Object cp) throws  
IllegalArgumentException, IllegalAccessException {

for(Field field : cp.getClass().getFields()) {
if(field.getType().isArray()) {
field.set(cp,  
newEmptyArray(field.getType().getComponentType()));

}
}
   }
}



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-29 Thread Jörg Schaible
Hi Oliver,

Oliver Heger wrote:

> Hi Jörg,
> 
> Am 28.04.2016 um 16:34 schrieb Jörg Schaible:
>> Chas Honton wrote:
>> 
>>> Try casting Object[] to long[]. The compiler and the runtime will
>>> complain.
>> 
>> It is not about a cast, it's about returning the proper object. And it
>> has nothing to do with primitives, because you cannot cast e.g. Object[]
>> to String[] either.
> 
> my first idea was the generic version, too. However, as Chas said, it is
> not possible to make a method with such a signature return an array of
> primitives. After type erasure, you have
> 
> public Object[] toArray(Class cls, String key)
> 
> and a primitive array is not an Object[].

The question is, why do we have getArray at all? These calls should be 
completely valid:

String[] strArray = conf.get(String[].class, "strings");
Integer[] integerArray = conf.get(Integer[].class, "integers");
int[] intArray = conf.get(int[].class, "ints");

... and I have implemented something like this in the past.

Method getArray should be deprecated immediately. Especially if it is not 
possible to use it in a type-safe way.

Cheers,
Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-28 Thread Oliver Heger
Hi Jörg,

Am 28.04.2016 um 16:34 schrieb Jörg Schaible:
> Chas Honton wrote:
> 
>> Try casting Object[] to long[]. The compiler and the runtime will
>> complain.
> 
> It is not about a cast, it's about returning the proper object. And it has 
> nothing to do with primitives, because you cannot cast e.g. Object[] to 
> String[] either.

my first idea was the generic version, too. However, as Chas said, it is
not possible to make a method with such a signature return an array of
primitives. After type erasure, you have

public Object[] toArray(Class cls, String key)

and a primitive array is not an Object[].

Oliver

> 
>>
>>> On Apr 27, 2016, at 11:59 PM, Jörg Schaible
>>>  wrote:
>>>
>>> Hi Oliver,
>>>
>>> Oliver Heger wrote:
>>>
 Hi Rainer,

> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
> Hi.
>
> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
> object, not an array of objects? Can somebody explain why the caller
> have to make an explicit cast?
>
> e.g.
> AbstractConfiguration  = ;
>
> Object obj = configuration.getArray(String.class, "key);
> // expected Object[] obj = configuration.getArray(String.class, "key);

 the explanation can be found in the Javadocs of the ConversionHandler
 interface which is used behind the scenes. Citing from the docs of the
 toArray() method:

 "Note that the result type of this method is Object; because this method
 can also produce arrays of a primitive type the return type Object[]
 cannot be used."
>>>
>>> That does not explain, why the method is not declared using generics:
>>>
>>>  public  T[] toArray(Class cls, String key);
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: user-h...@commons.apache.org
>>>
> 
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-28 Thread Jörg Schaible
Chas Honton wrote:

> Try casting Object[] to long[]. The compiler and the runtime will
> complain.

It is not about a cast, it's about returning the proper object. And it has 
nothing to do with primitives, because you cannot cast e.g. Object[] to 
String[] either.

> 
>> On Apr 27, 2016, at 11:59 PM, Jörg Schaible
>>  wrote:
>> 
>> Hi Oliver,
>> 
>> Oliver Heger wrote:
>> 
>>> Hi Rainer,
>>> 
 Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
 Hi.
 
 I wonder why AbstractConfiguration::getArray(cls, key) returns a single
 object, not an array of objects? Can somebody explain why the caller
 have to make an explicit cast?
 
 e.g.
 AbstractConfiguration  = ;
 
 Object obj = configuration.getArray(String.class, "key);
 // expected Object[] obj = configuration.getArray(String.class, "key);
>>> 
>>> the explanation can be found in the Javadocs of the ConversionHandler
>>> interface which is used behind the scenes. Citing from the docs of the
>>> toArray() method:
>>> 
>>> "Note that the result type of this method is Object; because this method
>>> can also produce arrays of a primitive type the return type Object[]
>>> cannot be used."
>> 
>> That does not explain, why the method is not declared using generics:
>> 
>>  public  T[] toArray(Class cls, String key);
>> 
>> Cheers,
>> Jörg
>> 
>> 
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-28 Thread Chas Honton
Try casting Object[] to long[]. The compiler and the runtime will complain. 

> On Apr 27, 2016, at 11:59 PM, Jörg Schaible  
> wrote:
> 
> Hi Oliver,
> 
> Oliver Heger wrote:
> 
>> Hi Rainer,
>> 
>>> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
>>> Hi.
>>> 
>>> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
>>> object, not an array of objects? Can somebody explain why the caller
>>> have to make an explicit cast?
>>> 
>>> e.g.
>>> AbstractConfiguration  = ;
>>> 
>>> Object obj = configuration.getArray(String.class, "key);
>>> // expected Object[] obj = configuration.getArray(String.class, "key);
>> 
>> the explanation can be found in the Javadocs of the ConversionHandler
>> interface which is used behind the scenes. Citing from the docs of the
>> toArray() method:
>> 
>> "Note that the result type of this method is Object; because this method
>> can also produce arrays of a primitive type the return type Object[]
>> cannot be used."
> 
> That does not explain, why the method is not declared using generics:
> 
>  public  T[] toArray(Class cls, String key);
> 
> Cheers,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: [configuration2]: AbstractConfiguration::getArray

2016-04-28 Thread Jörg Schaible
Hi Oliver,

Oliver Heger wrote:

> Hi Rainer,
> 
> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
>> Hi.
>> 
>> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
>> object, not an array of objects? Can somebody explain why the caller
>> have to make an explicit cast?
>> 
>> e.g.
>> AbstractConfiguration  = ;
>> 
>> Object obj = configuration.getArray(String.class, "key);
>> // expected Object[] obj = configuration.getArray(String.class, "key);
>> 
> 
> the explanation can be found in the Javadocs of the ConversionHandler
> interface which is used behind the scenes. Citing from the docs of the
> toArray() method:
> 
> "Note that the result type of this method is Object; because this method
> can also produce arrays of a primitive type the return type Object[]
> cannot be used."

That does not explain, why the method is not declared using generics:

  public  T[] toArray(Class cls, String key);

Cheers,
Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[configuration2]: AbstractConfiguration::getArray

2016-04-27 Thread Rainer Hirschmiller

Hi.

I wonder why AbstractConfiguration::getArray(cls, key) returns a single 
object, not an array of objects? Can somebody explain why the caller 
have to make an explicit cast?


e.g.
AbstractConfiguration  = ;

Object obj = configuration.getArray(String.class, "key);
// expected Object[] obj = configuration.getArray(String.class, "key);


Regards
Rainer

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org