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 >
