Yes but we need tons of methods then, one for List, Set, Map, SortedSet, SortedMap, MultiMap at least. Le 23 janv. 2015 07:16, "Oliver B. Fischer" <[email protected]> a écrit :
> Hi, > > I prefer the get(...)/getMultivalue(...) approach. > > Why? It leads to a cleaner API and expresses the expectation of user. Even > if TypeLiteral is working never liked the code I have to write for it. > > Bye, > > Oliver > > Am 21.01.15 um 11:46 schrieb Anatole Tresch: > >> Which is basically my original proposal. I would say, given what we have >> discussed so far, it would be interesting what others think. >> I personally also think the basic map design is sufficient. So lets focus >> a >> bit on that so we can then compare the possible solutions ;) >> >> Given that I would say we need: >> - TypeLiterals for being able to pass exactly what tsrget we expect >> - the possibility of having more control about how a final value is >> evaluated based on the values returned by the (multiple) property sources >> >> Both festures I think would also be useful for single values. So we might >> define a Functional interface PropertyCollector with: >> >> string collect(string currecurrentCollected, String newValue); >> >> Type conversion is still done with the PropertyConverter we already have >> in >> place. >> Wdyt? >> Romain Manni-Bucau <[email protected]> schrieb am Mi., 21. Jan. 2015 >> um >> 11:29: >> >> Point is if property source is responsible then converters are quite >>> useless or design is messy. Was surely a quick win solution but I'm >>> sure we can do something better. This is possible but change the >>> design we have of Map<String, String> more or less and moreover how >>> will you handle maps and other needs? I really think we should stick >>> to key=value and let converters handle other formats >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-21 11:03 GMT+01:00 Tresch, Anatole <anatole.tresch@credit-suisse. >>> com>: >>> (mail from Mark). One of the questions was how to support "arrays" at >>> all. >>> getList(String key); to the PropertySource. Advantage hereby is that the >>> property source >>> based on Strings. Basically this would work as well, though we would then >>> require >>> similar to a JDK 8 collector), because the current "default" strategy >>> simply overrides everything >>> what you want... >>> [email protected]>: >>> Given that we have 2 types of config entries returned by a PropertySource >>> 1) single value properties, 2) multi value (list properties). >>> the property source chain into one big list in sequence. The >>> MultiValueConverter then can decide what todo with them: >>> ordering, given the entries have some format, e.g. key:value, also a Map >>> can be created easily with similar possibilities about handling duplicate >>> keys etc. >>> PropertyConverter, just the for arrays... >>> ordering of ALL values as returned by various property sources for a key. >>> the converter then receives this ALL list and can do whatever is >>> appropriate... >>> [email protected]>: >>> case of the broader concept, multi-value support. >>> converter); >>> first class citizen, hereby keeping so we would end up in a pretty >>> symmetric API: >>> converter); >>> like: >>> single properties), we have a complete symmetric API >>> mailto:[email protected]>>: >>> functionality? >>> annotation >>> item >>> depending on >>> a >>> items >>> methods for >>> require >>> available that >>> the >>> e.g. >>> to the >>> itemType); >>> available that >>> e.g. >>> to the >>> converter, >>> e.g. >>> to the >>> <mailto:[email protected]>>: >>> [email protected]<mailto:[email protected]>> >>> >> > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf > >
