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