No simpler: List<Integer> get(key, new TamayaType<List<Integer>>(){});
Le 18 janv. 2015 19:37, "Werner Keil" <[email protected]> a écrit :> 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 > > >>> > > > >>> > > >> > > > > > > > > >
