commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [lang] Time for RC3?
Date Wed, 06 Jul 2011 08:52:06 GMT
Hi Stephen,

Stephen Colebourne wrote:

> On 4 July 2011 23:13, Jörg Schaible <> 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):

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:
For additional commands, e-mail:

View raw message