Not sure if I get your point. Originally we discussed several variants (mail from Mark). One of the questions was how to support "arrays" at all. It was the idea of Mark, to add an additional method String[] getList(String key); to the PropertySource. Advantage hereby is that the property source internally has control about the array formatting. Of course, we also could define some kind of syntax and do basically all based on Strings. Basically this would work as well, though we would then require to think on passing alternate combination strategies (or something similar to a JDK 8 collector), because the current "default" strategy simply overrides everything with the same key, which in case of collection entries is not always what you want...
-----Original Message----- From: Romain Manni-Bucau [mailto:[email protected]] Sent: Mittwoch, 21. Januar 2015 10:23 To: [email protected] Subject: Re: [DISCUSS] if and how to support Arrays in the config? hmm, this look overcomplicated to me since most of the time csv support in the Map will be enough (means any property source can contribute array friendly values) no? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-21 10:17 GMT+01:00 Tresch, Anatole <[email protected]>: > Hi Romain > > originally we discussed adding array support to the PropertySource. Given > that we have 2 types of config entries returned by a PropertySource 1) single > value properties, 2) multi value (list properties). > > Basically we can collect all the arrays returned by property sources in the > property source chain into one big list in sequence. The MultiValueConverter > then can decide what todo with them: > creating a set, but keep the ordering, creating a set, loose the 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. > This is basically exact the same we have with a normal PropertyConverter, > just the for arrays... > > So ordinal will sort the PropertySources and with that will define the > 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... > > Anatole > > > -----Original Message----- > From: Romain Manni-Bucau [mailto:[email protected]] > Sent: Mittwoch, 21. Januar 2015 09:30 > To: [email protected] > Subject: Re: [DISCUSS] if and how to support Arrays in the config? > > hmm I maybe didnt get it right > > multivalue means multiple time the same key? if yes ordinal will merge > them. If not and that's a CSV (or anything equivalent) value for a key > then TypeLiteral is enough, no need of any multi stuff. We just need > to provide few default literals, no? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-21 9:21 GMT+01:00 Tresch, Anatole <[email protected]>: >> Hi all >> >> >> >> I would even say, generally speaking, collections are only one use case of >> the broader concept, multi-value support. >> >> With normal value we do: >> >> >> >> String get(String key); >> >> <T> T get(String key, Class<T> type); >> >> <T> T get(String key, PropertyConverter<T> converter); >> >> >> >> Basically for multivalues we could do: >> >> >> >> List<String> getMultiValue(String key); >> >> <T> T getMultiValue(String key, TypeLiteral type); >> >> <T> T getMultiValue(String key, PropertyMultiValueConverter<T> converter); >> >> >> >> Looking at that we perhaps want to add TypeLiteral support more as a first >> class citizen, hereby keeping so we would end up in a pretty symmetric API: >> >> >> >> String get(String key); >> >> <T> T get(String key, Class<T> type); >> >> <T> T get(String key, TypeLiteral<T> type); >> >> <T> T get(String key, PropertyConverter<T> converter); >> >> >> >> Basically for multivalues we could do: >> >> >> >> List<String> getMultiValue(String key); >> >> <T> T getMultiValue(String key, TypeLiteral<T> type); >> >> <T> T getMultiValue(String key, Class<T> type); >> >> <T> T getMultiValue(String key, PropertyMultiValueConverter<T> converter); >> >> >> >> >> >> For completeness sake the PropertyMultiValueConverter<T> would look like: >> >> >> >> public interface ListPropertyConverter<T> { >> >> T convert(List<String> values) ; >> >> } >> >> >> >> IMO this would be a good compromise: we have all flexibility (also for >> single properties), we have a complete symmetric API >> >> and still its quite small… >> >> The only disadvantage is we have to add some TypeLiteral type… >> >> >> >> Anatole >> >> >> >> >> >> -----Original Message----- >> From: Romain Manni-Bucau [mailto:[email protected]] >> Sent: Mittwoch, 21. Januar 2015 08:37 >> To: [email protected] >> Subject: Re: [DISCUSS] if and how to support Arrays in the config? >> >> >> >> we should support it IMO (=converter in java 8 module maybe) but it >> >> can't be the first citizen since most of the time for a config you >> >> dont' want just streams and need List or Set features (Collection and >> >> Iterable are not enough). Since we can get them for free and stream >> >> are just one method call (java 8 loves it :p) then not sure it is an >> >> issue >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-21 8:22 GMT+01:00 Oliver B. Fischer >> <[email protected]<mailto:[email protected]>>: >> >>> Why can't we use the stream collectors of Java 8 or similar functionality? >> >>> >> >>> Oliver >> >>> >> >>> >> >>> >> >>> Am 20.01.15 um 00:47 schrieb Anatole Tresch: >> >>>> >> >>>> Of course, nevertheless we could do something like that: >> >>>> >> >>>> public interface ListPropertyConverter<T> { >> >>>> Class<T> getTargetType(); // or better use @ConverterSpec annotation >> >>>> T convert(List<String> values, List<PropertyConverter<I>> >> >>>> propertyConverter); >> >>>> } >> >>>> >> >>>> This is the same principle as applied with single valued >> >>>> PropertyConverters. >> >>>> The only difference is that, we pass to the ListPropertyConverter >> >>>> additionally >> >>>> the item converters to be used (alternatively we could also pass the item >> >>>> type, but in that case different parsing behaviour may result depending on >> >>>> the List converter implementation). >> >>>> >> >>>> So the PropertyListConverter implementation is responsible for >> >>>> creating the *list >> >>>> property type*, whatever it is. It could be a List, an Array, a Map, a >> >>>> tree, or something completely different, whereas the parsing of the items >> >>>> contained in the list is done by the PropertyConverters in place. >> >>>> >> >>>> On API side (Configuration) we simply could add two additional methods for >> >>>> Java 7: >> >>>> >> >>>> /** >> >>>> * Get the list property key as type T. This will implicitly require >> >>>> a >> >>>> corresponding {@link >> >>>> * org.apache.tamaya.spi.ListPropertyConverter} to be available that >> >>>> is >> >>>> capable current providing type T >> >>>> * and corresponding {@link PropertyConverter} for converting the >> >>>> single items to their required >> >>>> * target type {@code itemType}. >> >>>> * >> >>>> * @param key the property's absolute, or relative path, e.g. >> >>>> @code >> >>>> * a/b/c/d.myProperty}. >> >>>> * @param type The target type required, not null. >> >>>> * @param itemType The item type to be passed to the {@link >> >>>> org.apache.tamaya.ListPropertyConverter}. >> >>>> * @return the property value, never null.. >> >>>> * @throws ConfigException if the keys could not be converted to the >> >>>> required target type. >> >>>> */ >> >>>> <T> T getListProperty(String key, Class<T> type, Class<?> itemType); >> >>>> >> >>>> /** >> >>>> * Get the list property key as type T. This given {@link >> >>>> * org.apache.tamaya.spi.ListPropertyConverter} to be available that >> >>>> is >> >>>> capable current providing type T >> >>>> * is used, hereby creating items of type {@code itemType}. >> >>>> * >> >>>> * @param key the property's absolute, or relative path, e.g. >> >>>> @code >> >>>> * a/b/c/d.myProperty}. >> >>>> * @param converter the {@link >> >>>> org.apache.tamaya.ListPropertyConverter} >> >>>> used, not null. >> >>>> * @param itemType The item type to be passed to the {@link >> >>>> org.apache.tamaya.ListPropertyConverter}. >> >>>> * @return the property value, never null.. >> >>>> * @throws ConfigException if the keys could not be converted to the >> >>>> required target type. >> >>>> */ >> >>>> <T> T getListProperty(String key, ListPropertyConverter<T> converter, >> >>>> Class<?> itemType); >> >>>> >> >>>> >> >>>> ...and one method for Java 8, enabling functional support: >> >>>> >> >>>> /** >> >>>> * Get the list property key as type T, hereby using the given >> >>>> function >> >>>> for conversion. >> >>>> * >> >>>> * @param key the property's absolute, or relative path, e.g. >> >>>> @code >> >>>> * a/b/c/d.myProperty}. >> >>>> * @param converter the conversion function to be used. >> >>>> * @return the property value, never null.. >> >>>> * @throws ConfigException if the keys could not be converted to the >> >>>> required target type. >> >>>> */ >> >>>> <T> T getListProperty(String key, Function<List<String>, T> >> >>>> converter); >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> 2015-01-18 22:23 GMT+01:00 Werner Keil >>>> <[email protected]<mailto:[email protected]>>: >> >>>> >> >>>>> Map is another interface not related to Collection as such. >> >>>>> If we must return each of them separately, it may have to be on a >> >>>>> case-by-case basis;-) >> >>>>> >> >>>>> Werner >> >>>>> >> >>>>> On Sun, Jan 18, 2015 at 10:11 PM, Anatole Tresch >>>>> <[email protected]<mailto:[email protected]>> >> >>>>> wrote: >> >>>>> >> >>>>> implementation >> >>>>> items >> >>>>> least >> >>>>> will >> >>>>> ListPropertyConverters. >> >>>>> too) >> >>>>> by >> >>>>> could >> >>>>> it >> >>>>> AnnotationLiteral >> >>>>> bad >> >>>>> resolved >> >>>>> to >> >>>>> 17. >> >>>>> what >> >>>>> use >> >>>>> towards >> >>>>> e.g. >> >>>> >> >>>> >> >>>> >> >>> >> >>> -- >> >>> N Oliver B. Fischer >> >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany >> >>> P +49 30 44793251 >> >>> M +49 178 7903538 >> >>> E [email protected]<mailto:[email protected]> >> >>> S oliver.b.fischer >> >>> J [email protected]<mailto:[email protected]> >> >>> X http://xing.to/obf >> >>>
