My idea was Map (compared to properties) has already a nice and java 8 API so we don't need to add another one on top of it (+ it doesnt break java 7 API as well). Less we introduce of concepts better we'll be IMO - easier to use/understand.
I agree about not scannable properties...but I doubt it is a real issue in practise, these ones will be very very limited so ignoring them here shouldn't be a big deal. They are by design "broken" sources. Even thought replacing isScannable() by @NotScannable to not make this property a first citizen of the PropertySource API. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-23 8:38 GMT+01:00 Anatole Tresch <[email protected]>: > Reading again I am sure I get your point ;) > What benefits should the convertermanager bring? What api? I dont see the > connection to my post. Pleae help! > Anatole Tresch <[email protected]> schrieb am Fr., 23. Jan. 2015 um 08:20: > >> 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 >>> >> > >>> >> > >>> >> >>> >>
