uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Kottmann <kottm...@gmail.com>
Subject Re: generics: additionalParams
Date Wed, 19 Aug 2009 12:42:40 GMT
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> Jörn Kottmann wrote:
>>> The additionalParams Map has a String key and can contains
>>> all kinds of Objects, so the correct generification would be
>>> Map<String, Object>.
>>> In the uima code base I found one invocation where a Properties object
>>> was
>>> passed as additionalParams. Properties is a Map<Object, Object> which
>>> will cause compile errors in user code when they use a Properties
>>> object to pass
>>> in the additional params.
>>> I don't think its common practice to use Properties for additional
>>> params.
>> If we fix the one found use cited above, are there any other cases where
>> instances of Properties are passed as additionalParams in our own code? 
>> What do we think is the likelyhood that users will use Properties as
>> instances of additional params?
>> Our documentation says "See the Javadocs" for info on the additional
>> parameters.  The Javadocs say this is a Map ... Valid parameter names
>> are defined as constants on the XYZ Interface ... and in that interface,
>> these constants are Strings.
>> But users might decide to represent these parameters in a properties file.
>> Here are some considerations (apologies if I get this wrong - please
>> correct):
>>  - If we declare as <Object, Object>, then you cannot assign a
>> Map<String, Object> to the parameter.
>>  - Having the key of the map be an Object is more general, and would
>> accommodate Properties.
>>  - declaring as <String, Object> - cannot assign  "new Properties()" to
>> it any more, unless you do the double-fisted cast
>> (Map<String,Object>)(Object)
>> If that is the trade off, I think I would rather have it be <String,
>> Object>.
> +1 from me for Map<String, Object>
If there are no objections I would like to start with the change
to get it done before our 28th deadline.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message