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
