Daniel Rall wrote:
>
> Why does Context's getKeys() instance method return a Object[],
> containsKey() take an Object, etc. when the keys are all Strings
> (enforced by the String key parameter of the sole key/value pair
> insertion method, put())?
>
> Daniel
The type-safety is a bless to some, a curse to others. One ugly
thing about Java is that it does not allow casting:
String[] strings = (String[]) objectArray;
You need to do:
String[] strings = new String[objectArray.length]
System.arraycopy(objectArray, 0, strings, 0, objectArray.length);
The reason for Context.getKeys() returning an Object[] is that
this allows using generic classes like the Arrays.sort(...) and
the similar, which always take Object[] as parameters... Check
yourself the parameters of all your sources: more Object[] than
String[]!.
The Set interface also defines a toArray() method returning an
Object[] for the same reason. Now that Vel uses an ArrayList
for ranges, we are locked to use context tools that take Object[]
(or Set interface) as parameters.
I have a context tool that has a getItem(Object[], index) method
which would not work if you try to call it in a template with
a String[].
For VTL it does not matter if it is a Object[] or String[] in
a #foreach!
I guess these are enough reasons (and initial arraycopy solution)
to justify the Object[]
:) Chirstoph
