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