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 >> >>>
