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