Hi Stephen, Stephen Colebourne wrote:
> On 4 July 2011 23:13, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> Sorry, why is setValue more vague - isn't it the other way round? > As a method name, replace is explicit, set slightly less so. Either > work here, so if you want to change it go ahead. May be I am simply biased, because Commons Configuration uses also this naming scheme (addProperty/setProperty): http://commons.apache.org/configuration/apidocs/org/apache/commons/configuration/Configuration.html However, the semantic is more important. I want a method where I can put a value into the context that sets or replaces anything using the same key. An implementation is worthless to me that is free to simply drop the value because the context does not yet contain the key. As long the methods work as they are currently described (independent of their names) I will have to code that clutter from my last example. > More generally, I now think the index suffix scheme is wrong. It > should collect a list of data for the same key, because otherwise you > can't look up the data later (as the key has been silently changed > behind your back). API methods: > > List<String> getValues(String key) > String getFirstValue(String key) Oliver made the same recommendation. However, then we lose the sequence in which the values were added completely. In a recursive situation you might have currently an output for the contexted exception message like this: InvalidDataException: Failed to read company data Context values: Causing Message: Invalid format Handler Name: IntConverter Current Element: age Handler Name[1]: PersonConverter Current Element[1]: cto Name: John Doe Handler Name[2]: DepartmentConverter Current Element[2]: dep Department: Management Handler Name[3]: CompanyConverter Current Element[3]: company Name[1]: ACME Inc. I can traverse now the set of keys to get this list when it is internally implemented with a LinkedHashMap. Remember, one important element of a contexted exception is a more informational and structured message. In the list above I can see quite immediately where the problem is and in which way the application flow failed. Any idea how we could improve the API to support this with an implementation? Something like: List<Pair<String, Object>> getEntries(); Not very nice for an implementation, I know. > If its pluggable then an alternative implementation could not use a > list and only keep the first or last value. The default implementation > should keep all the values. At least I want to have a useful API with a contract that does not arbitrarily may drop my data. Think of the Java Map. An implementation might violate the contract on purpose (WeakHashMap, IdentityHashMap), but for your standard usage, you have a very clear idea what any Map does. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
