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]> wrote: > I personally see three types of "collections" useful: > > 1) List > 2) Set > 3) Map > > IMO it is sufficient to let Tamaya support these ones, if users have > special requirements, like sorting, reordering, using their implementation > types, they still can apply them on the result returned, or copy the items > into their own data structure, or using streams. > > As mentioned we have basically two options where transformation from the > internal "Config Format" into the collection can be implemented: > > 1) by a mechanism applied during configuration read, e.g. a > PropertyConverter as we have of now. This has > several drawbacks IMO: > - This requires to have a textual representation of all supported > collection types. > - This will be IMO very error prone. > - It implies configuration aspects into the PropertySource, or at least > how it must be delivered. > - Overriding is inflexible, because our system currently only knows > full overrides replacing all contents present > before. Introducing Override policies as suggested by me earlier will > make things much more complex, so > this is not an option I think.. > 2) within the property source, looks more promising I think: > + the effective format, how config is mapped, can be hidden by the > PropertySource implementation > + returning a String[] (or List) as part of a property source is not > very powerful, but basically enough, since I > can convert a ordered list of all items encountered to everything > above. For that I propose to define > a ListPropertyConverter that converts from String[]/List<String> to > whatever is needed: Set, Map, List, Tree or whatever. > > So summarizing I would propose (discussion base): > > - I) Add List<String> getListProperty(String key) to PropertySource. > - II) Add a ListPropertyConverter interface as follows: > > public interface ListPropertyConverter<C extends Collection<T>, T> { > > /** > * Convert the given configuration values from it's String > representation into the required target type. > * Hereby the item values must be of type T. For maps an instance of > {@code Map<String,T>}, for > * other collections an instance of {@code Collection<T>} must be > returned. > * > * *@param values the configuration values found in order of as > delivered by the property source chain.* > * * It is possible that similar items are present > multiple times. Depedning on the output* > * * collection type produced duplicates may be removed, > or handled in alternative ways* > * * as needed.* > * @return the converted value > */ > C convert(List<String> values); > } > > > - III) define/add an > annotation > for converters > , e.g. @ConfigConverterSpec( > Class<?> targetType > , Class > <?> itemType default Class.class > ), > so we > can still define PropertyConverter as well as PropertyListConverter > as > functional interfaces. > > > - IV) > ConfigurationContext can be extended similarly > , by adding similar converter support for list ListPropertyConverters. > > > > - V) > Configuration > would be > > extended with > the following methods: > > <T> List<T> getList(String key, Class<T> itemType); > <T> List<T> getList(String key, > > PropertyListConverter<List<T>, T> converter); > > <T> Set<T> > > getSet(String key, Class<T> itemType); > > > <T> Set<T> > > getSet(String key, > > > PropertyListConverter<Set<T>, T> converter); > <T> Map > <String,T> > > get > Map > (String key, Class<T> itemType); > > > > <T> > Map > <String,T> > > get > Map > (String key, > > > PropertyListConverter<Set<T>, T> converter); > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thats all of the magic I would need: > > - I have support for set, lists and maps > - I have defined the required target type: > - when passing the itemType only it would require a corresponding > PropertyAdapter for the type to be present > - I can have full control by passing my own PropertyListConverter > similar > I can do with single values using PropertyConverter > > BTW: PropertyConverter currently is part of the SPI. But since I can pass > it as well as parameter to the API IMO it belongs to the API package... > > WDYT? > > Cheers, > Anatole > > > > > 2015-01-18 19:35 GMT+01:00 Werner Keil <[email protected]>: > > > Well I did not suggest Converters, maybe Romain referred to a different > > part of the API (though his example signature mentioned a Converter, too) > > If you have a method: > > Collection<T> getAll() returning a Collection which is in fact backed by > a > > LinkedList or another List, why would you lose its order if you cast it > to > > a List? > > > > Trying to cast to say a Set would produce a ClassCastException, one could > > check this before trying to cast, but if the underlying type is a List it > > remains a list. > > > > Werner > > > > On Sun, Jan 18, 2015 at 7:27 PM, Mark Struberg <[email protected]> > wrote: > > > > > Converters (PropertyAdaptors) do convert the values INSIDE the list. > You > > > would not be able to distinguish properly. > > > > > > And casting this to a sorted List makes no sense at all if there are > Sets > > > used in PropertySources or anywhere in the Configuration system where > you > > > would loose the natural (configured) original order. > > > > > > LieGrue, > > > strub > > > > > > On Sunday, 18 January 2015, 18:31, Romain Manni-Bucau < > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > >Guys we have converters so why do we discuss type? > > > >Are converters not able to handle it? If so we have to update them > > > removing Class for Type...btw we shouldnt have getTargetType but we > > should > > > use reflection to get it and keep api clean IMO. See AnnotationLiteral > or > > > TypeLiteral class for samples. > > > >Le 18 janv. 2015 18:28, "Werner Keil" <[email protected]> a > écrit : > > > > > > > >Would it be a sacrileg having to cast a Collection to a List or Set > > > then?;-) > > > >> > > > >>Werner > > > >> > > > >>On Sun, Jan 18, 2015 at 3:15 PM, Mark Struberg <[email protected]> > > > wrote: > > > >> > > > >>> Sometimes sorting MIGHT be important. Consider you configure a > > weighted > > > >>> list of valid options. Where the one listed first is the most > > imported > > > one. > > > >>> > > > >>> LieGrue, > > > >>> strub > > > >>> > > > >>> > > > >>> > > > >>> > On Sunday, 18 January 2015, 13:43, Oliver B. Fischer < > > > >>> [email protected]> wrote: > > > >>> > > Hi, > > > >>> > > > > >>> > this issue occured already multiple times on this list. > > > >>> > > > > >>> > I prefer 2b but I would return a set or collection. Sorting is > not > > > >>> > important as it can be done easily later. > > > >>> > > > > >>> > But I think the method to access all values must be able to > perform > > > type > > > >>> > conversion as > > > >>> > > > > >>> > get(String key, PropertyConverter<T> converter) > > > >>> > > > > >>> > method. > > > >>> > > > > >>> > My prefered signature looks like this > > > >>> > > > > >>> > Collection<T> getAll(String key, ProperyConverter<T> converter) > > > >>> > > > > >>> > > > > >>> > WDYT? > > > >>> > > > > >>> > Bye > > > >>> > > > > >>> > Oliver > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > Am 17.01.15 um 19:51 schrieb Anatole Tresch: > > > >>> >> My views are 1b. > > > >>> >> > > > >>> >> I am not sure that we can model all aspects with 2b1, so 2a > might > > > also > > > >>> be a > > > >>> >> way out, because it would allow us to model the feature as an > > > optional > > > >>> >> module. > > > >>> >> > > > >>> >> Here is way: > > > >>> >> > > > >>> >> Mapping of lists, arrays work fine with 2b1. Sets may work as > > well, > > > >>> whereas > > > >>> >> maps dont really fit. > > > >>> >> On top i ask how overriding should work (this question is > raising > > > for > > > >>> both > > > >>> >> 2b1 and 2a. With 2a we have a clear rule, though it might not > > match > > > >>> all use > > > >>> >> cases, eg collecting all items configured). > > > >>> >> > > > >>> >> Given that imo its arguable if a simple additional array > accessor > > > is > > > >>> >> sufficient... > > > >>> >> > > > >>> >> All these additional aspects are the ones why Looking for > > modelling > > > >>> >> collections based on simple key/value pairs might be not a bad > > > >>> solution. > > > >>> >> Collections may be mapped to multiple key/value pairs, resolved > > by > > > >>> filters. > > > >>> >> We can even add collection accessors of any complexity as > > queries, > > > >>> being > > > >>> >> much more flexible than trying to model / reduce everything to > a > > > simple > > > >>> >> array/list... > > > >>> >> > > > >>> >> Other thaughts...? > > > >>> >> > > > >>> >> Anatole > > > >>> >> > > > >>> >> Romain Manni-Bucau <[email protected]> schrieb am Sa., 17. > > > Jan. > > > >>> > 2015 um > > > >>> >> 13:25: > > > >>> >> > > > >>> >>> 1a and same support as xbean ie you ask and converters do what > > > they > > > >>> can > > > >>> > or > > > >>> >>> fail > > > >>> >>> Le 17 janv. 2015 12:56, "Werner Keil" > > > >>> > <[email protected]> a écrit : > > > >>> >>> > > > >>> >>>> Well, I remember a JSR (not sure which one any more) that > > changed > > > >>> > such > > > >>> >>>> return value or argument from List to Collection to be more > > > >>> > versatile. > > > >>> >>>> If you have the restriction of unique values then better use > a > > > Set. > > > >>> >>> There's > > > >>> >>>> also a SortedSet, so all can be sorted, but if you return > them > > as > > > >>> > List > > > >>> >>>> only, that excludes Set and vice versa. Returning as > Collection > > > >>> > allowed > > > >>> >>> to > > > >>> >>>> treat them specifically to what they really are, if you > return > > > just > > > >>> > one > > > >>> >>> of > > > >>> >>>> the subtypes, you restrict users from the other. > > > >>> >>>> > > > >>> >>>> Werner > > > >>> >>>> > > > >>> >>>> On Sat, Jan 17, 2015 at 12:47 PM, Mark Struberg > > > >>> > <[email protected]> > > > >>> >>> wrote: > > > >>> >>>>> The underlying question is whether sorting is important or > > not. > > > >>> >>>>> I think it is, and thus I'd prefer a List. > > > >>> >>>>> > > > >>> >>>>> LieGrue, > > > >>> >>>>> strub > > > >>> >>>>> > > > >>> >>>>> > > > >>> >>>>> > > > >>> >>>>> > > > >>> >>>>>> On Saturday, 17 January 2015, 12:35, Werner Keil < > > > >>> >>>> [email protected]> > > > >>> >>>>> wrote: > > > >>> >>>>>>> About 3) > > > >>> >>>>>> I would return a Collection which is the most common > > > >>> > foundation to > > > >>> >>> both > > > >>> >>>>>> List and Set. Unless there was a special requirement > > > >>> > somewhere like > > > >>> >>> "no > > > >>> >>>>>> duplicates" that's where a Set would be better. > > > >>> >>>>>> > > > >>> >>>>>> And if Tamaya supports collections I am not biased towards > > > >>> > arrays, > > > >>> >>>> since > > > >>> >>>>> in > > > >>> >>>>>> most cases you can use both in a very similar way now, e.g. > > > >>> > loop over > > > >>> >>>>> them. > > > >>> >>>>>> Werner > > > >>> >>>>>> > > > >>> >>>>>> > > > >>> >>>>>> On Sat, Jan 17, 2015 at 9:51 AM, Mark Struberg > > > >>> > <[email protected]> > > > >>> >>>>> wrote: > > > >>> >>>>>>> Hi! > > > >>> >>>>>>> > > > >>> >>>>>>> 1.) Do we like to support arrays at all? > > > >>> >>>>>>> > > > >>> >>>>>>> 1.a.) yes, in any case. They are really needed. > > > >>> >>>>>>> 1.b.) yes, if we can do easily. They are nice to > > > >>> > have. But only if > > > >>> >>>>> easily > > > >>> >>>>>>> doable. > > > >>> >>>>>>> 1.c.) Nope, we don't need it. A user can easily > > > >>> > add this himself by > > > >>> >>>>>>> String.split, etc > > > >>> >>>>>>> > > > >>> >>>>>>> I'd prefer 1.b.) > > > >>> >>>>>>> > > > >>> >>>>>>> > > > >>> >>>>>>> How to support arrays. Do we like to > > > >>> >>>>>>> 2.a.) map them to String representation or do we like > > > >>> > to > > > >>> >>>>>>> 2.b.) have a String[] getArray(String key) in our > > > >>> > PropertySource. > > > >>> >>> In > > > >>> >>>>> that > > > >>> >>>>>>> case > > > >>> >>>>>>> 2.b.1.) do we like to have String[] getArray(key) in > > > >>> > addition to > > > >>> >>>> String > > > >>> >>>>>>> get(key) or > > > >>> >>>>>>> 2.b.2.) only have String[] get(key) and only return a > > > >>> > single value > > > >>> >>> in > > > >>> >>>>> it > > > >>> >>>>>>> for a get(key) call? > > > >>> >>>>>>> > > > >>> >>>>>>> > > > >>> >>>>>>> I personally like 2.b.1 the most, but not 100% sure > > > >>> > yet. > > > >>> >>>>>>> > > > >>> >>>>>>> > > > >>> >>>>>>> > > > >>> >>>>>>> 3.) What type should we return at all? > > > >>> >>>>>>> 3.a.) Should we return [] > > > >>> >>>>>>> 3.b.) or List? > > > >>> >>>>>>> 3.c.) Or even a Set? > > > >>> >>>>>>> > > > >>> >>>>>>> I'd prefer 3.a or 3.b as the order sometimes is > > > >>> > important. We could > > > >>> >>>>>> also > > > >>> >>>>>>> think about enhancing the Filter to allow re-sorting > > > >>> > those values > > > >>> >>> if > > > >>> >>>>>> needed. > > > >>> >>>>>>> We also have to think about at which point we apply > > > >>> > the > > > >>> >>>>> PropertyAdapter. > > > >>> >>>>>>> I'd also love to have something like getArray (or > > > >>> > getList if we > > > >>> >>>> decide > > > >>> >>>>>> on > > > >>> >>>>>>> that) > > > >>> >>>>>>> <T> T[] getArray(String key), Class<T> > > > >>> > targetType); > > > >>> >>>>>>> Where each value in the String[] gets converted with > > > >>> > the > > > >>> >>>>> PropertyAdapters > > > >>> >>>>>>> already inside Tamaya. > > > >>> >>>>>>> > > > >>> >>>>>>> Any thoughts? > > > >>> >>>>>>> > > > >>> >>>>>>> > > > >>> >>>>>>> LieGrue, > > > >>> >>>>>>> strub > > > >>> >>>>>>> > > > >>> > > > > >>> > -- > > > >>> > 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 > > > >>> > > > > >>> > > > >> > > > > > > > > > > > > > > > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >
