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