2010/8/10 sebb <seb...@gmail.com>:
> On 9 August 2010 23:44, James Carman <ja...@carmanconsulting.com> wrote:
>> On Mon, Aug 9, 2010 at 7:32 AM, sebb <seb...@gmail.com> wrote:
>>> Why not split the code into two methods:
>>>
>>> public static <K,V> Map<K, V> toMap(Map.Entry<K,V>[] array)
>>> and
>>> public static <K,V> Map<K, V> toMap(Class<K> keyType, Class<V>
>>> valueType, Object[][] array)
>>>
>>
>> So, what would that make the "user" code look like? The whole reason
>> for this, unless I'm mistaken, was to make it easy to do stuff like:
>>
>> public static final Map<String,Color> COLOR_MAP = ArrayUtils.toMap(new
>> Object[][] {
>> { "red", Color.red },
>> { "blue", Color.blue }
>> } );
>>
>> To me, we're really trying to make it easier to use this API, right?
>> So, now the code would look like:
>>
>> public static final Map<String,Color> COLOR_MAP =
>> ArrayUtils.toMap(String.class, Color.class, new Object[][] {
>> { "red", Color.red },
>> { "blue", Color.blue }
>> } );
>>
>
> Looks OK to me, and solves the type-safety problem.
>
>> This is one of the big gripes about how generics are handled in Java,
>> you have to repeat yourself so darn much. What if we told folks to
>> use a new MapBuilder instead?
>>
>> public static final Map<String,Color> COLOR_MAP =
>> MapUtils.builder().put("red", Color.red).put("blue",
>> Color.blue).toMap();
>>
>> It seems like this "builder" stuff is getting popular these days.
>> What do you guys think?
>
> AFAICT, that does not ensure type-safety, so is no better than the current
> API.
>
The builder can ensure type-safety, if the builder itself is generic:
MapBuilder<K, V>, with methods:
- void put(K key, V value)
- Map<K, V> toMap()
and MapUtils method is:
public static <K, V> MapBuilder<K, V> builder();
(And the MapBuilder looks awfully a lot like Map ;-) )
>> ---------------------------------------------------------------------
>> 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
