Hello Jody Jody Garnett a écrit : > What you have written is parameter where Maps which map to values of the > same type can be provided ... examples: > - Map<String,Integer> - you can have any value you want as long as it is > an Integer > - Map<String,String> - traditional property file > - Map<String,Serializable> - my personal favourite > - Map<String,Object> - anything goes > > My guess is you intended the last entry ....in order to allow mix values
Yes, the intented behavior is as Map<String,Object>. However the Map<String,?> signature allow users to pass a Map<String,Integer>, Map<String,String>, etc. if they wish. We could want to restrict the type to Map<String,Object> if we were keeping a reference to it. But we don't. The constructor extracts the values from the map and assigns appropriate private fields accordingly. It is like a copy. For this reason, the actual type of the user-provided map doesn't matter since we keep no trace of it. This is similar in spirit to HashMap(Map) constructor (a copy constructor), which copies the value of a map in the new map: http://java.sun.com/javase/6/docs/api/java/util/HashMap.html#HashMap(java.util.Map) Note the signature, which is Map<? extends K, ? extends V>, not Map<K,V>. > I would urge you to consider Map<String,Serializable> however as it is > very friendly to people who want to save and restore objects... We could... But it would not make much difference since DefaultEngineeringDatum constructor (and all referencing object constructors) are copy constructors, so the map is not retained and not serialized. DefaultEngineeringDatum itself is Serializable. The only hole I can see would be if a Map value is a non-serializable implementation of InternationalString. All GeoTools implementations are serializable as far as I know. If nevertheless we hit a non-serializable instance, it is probably possible to handle that case at referencing object serialization time. Changing the signature to Map<String,? extends Serializable> would force GeoAPI Factory to change their signature in the same way. We could imagine non-GeoTools implementations wanting to create objects that are not serializable for whatever reasons (e.g. depends on a live connection to a database, etc.). It may be less disruptive to check for Serializable InternationalString in referencing object constructors instead, if we need them to be serializable. Martin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
