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 >
