Hi Anatole, reading your last point I'm tempted to say if we export the config as a map it is doable through converter API so maybe we should give them a bit more space in the API (config.getConverterManager() maybe)
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-23 7:49 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Oliver > > The TypeLiteral is also very useful for non muli values. Eg if someone > wants to access a parametrized type from a single value. So I think > alternatives not using it are worse. > > I personally clearly prefer the pure String,String design ( especially > since i played araound with multiple alternatives in code ). Multivalues > can be done with that as well and it adds unnecessary complexity on > propertysource. Also it adds basically a redundant level of config: it is > not sufficient to say.I read key 'x.y'. I also must say if I read a single > or a multivalue. So we have logically two redundant config layers. For me a > no go. > > Said that for me the outcome is clear: > - we dont need multivalues > - we need typeliterals in addition to what we have. > - we need control about the mechanism that is combining entries of > subsequent proptertsourced, still keeping overrides as default: therefore I > proposed the ValueCollector interface. > Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. 2015 um > 07:28: > >> 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 >> > >> > >>
