Re: generics: additionalParams
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 MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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 MapString, 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 (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. +1 from me for MapString, Object If there are no objections I would like to start with the change to get it done before our 28th deadline. Jörn
Re: generics: additionalParams
+1 Marshall Jörn Kottmann wrote: 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 MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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 MapString, 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 (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. +1 from me for MapString, Object If there are no objections I would like to start with the change to get it done before our 28th deadline. Jörn
Re: generics: additionalParams
Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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. Any opinions on this ? Jörn
Re: generics: additionalParams
Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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 MapString, 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 (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. -Marshall Should we change it anyway and add a known issue to our release notes ? Jörn
Re: generics: additionalParams
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 MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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? There was only one case in the uimaj code base (I did not check sandbox). 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 MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. If you prefer the option to have an Object as key the map could be declared as Map?, ?. Having a map which contains objects of an unkown type has the disadvantage that it is not possible to insert new objects, which is something we do frequently in our implementations. Jörn
Re: generics: additionalParams
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 MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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? There was only one case in the uimaj code base (I did not check sandbox). 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 MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. If you prefer the option to have an Object as key the map could be declared as Map?, ?. Having a map which contains objects of an unkown type has the disadvantage that it is not possible to insert new objects, which is something we do frequently in our implementations. hmmm, yes, that would seem to be a pretty strong reason not to use that form ;-) -Marshall Jörn
Re: generics: additionalParams
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 MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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 MapString, 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 (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. +1 from me for MapString, Object Jörn
generics: additionalParams
The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, 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. Should we change it anyway and add a known issue to our release notes ? Jörn
