Hi Romain 1) We already have getProperties() 2) non scannable propertysources may be not considered: really bad 3) i need the feature only for single keys typically.
So I dont agree ;) Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. 2015 um 07:54: > 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 > >> > > >> > > >> >
