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