I personally see three types of "collections" useful:
1) List
2) Set
3) Map
IMO it is sufficient to let Tamaya support these ones, if users have
special requirements, like sorting, reordering, using their implementation
types, they still can apply them on the result returned, or copy the items
into their own data structure, or using streams.
As mentioned we have basically two options where transformation from the
internal "Config Format" into the collection can be implemented:
1) by a mechanism applied during configuration read, e.g. a
PropertyConverter as we have of now. This has
several drawbacks IMO:
- This requires to have a textual representation of all supported
collection types.
- This will be IMO very error prone.
- It implies configuration aspects into the PropertySource, or at least
how it must be delivered.
- Overriding is inflexible, because our system currently only knows
full overrides replacing all contents present
before. Introducing Override policies as suggested by me earlier will
make things much more complex, so
this is not an option I think..
2) within the property source, looks more promising I think:
+ the effective format, how config is mapped, can be hidden by the
PropertySource implementation
+ returning a String[] (or List) as part of a property source is not
very powerful, but basically enough, since I
can convert a ordered list of all items encountered to everything
above. For that I propose to define
a ListPropertyConverter that converts from String[]/List<String> to
whatever is needed: Set, Map, List, Tree or whatever.
So summarizing I would propose (discussion base):
- I) Add List<String> getListProperty(String key) to PropertySource.
- II) Add a ListPropertyConverter interface as follows:
public interface ListPropertyConverter<C extends Collection<T>, T> {
/**
* Convert the given configuration values from it's String
representation into the required target type.
* Hereby the item values must be of type T. For maps an instance of
{@code Map<String,T>}, for
* other collections an instance of {@code Collection<T>} must be
returned.
*
* *@param values the configuration values found in order of as
delivered by the property source chain.*
* * It is possible that similar items are present
multiple times. Depedning on the output*
* * collection type produced duplicates may be removed,
or handled in alternative ways*
* * as needed.*
* @return the converted value
*/
C convert(List<String> values);
}
- III) define/add an
annotation
for converters
, e.g. @ConfigConverterSpec(
Class<?> targetType
, Class
<?> itemType default Class.class
),
so we
can still define PropertyConverter as well as PropertyListConverter
as
functional interfaces.
- IV)
ConfigurationContext can be extended similarly
, by adding similar converter support for list ListPropertyConverters.
- V)
Configuration
would be
extended with
the following methods:
<T> List<T> getList(String key, Class<T> itemType);
<T> List<T> getList(String key,
PropertyListConverter<List<T>, T> converter);
<T> Set<T>
getSet(String key, Class<T> itemType);
<T> Set<T>
getSet(String key,
PropertyListConverter<Set<T>, T> converter);
<T> Map
<String,T>
get
Map
(String key, Class<T> itemType);
<T>
Map
<String,T>
get
Map
(String key,
PropertyListConverter<Set<T>, T> converter);
Thats all of the magic I would need:
- I have support for set, lists and maps
- I have defined the required target type:
- when passing the itemType only it would require a corresponding
PropertyAdapter for the type to be present
- I can have full control by passing my own PropertyListConverter similar
I can do with single values using PropertyConverter
BTW: PropertyConverter currently is part of the SPI. But since I can pass
it as well as parameter to the API IMO it belongs to the API package...
WDYT?
Cheers,
Anatole
2015-01-18 19:35 GMT+01:00 Werner Keil <[email protected]>:
> Well I did not suggest Converters, maybe Romain referred to a different
> part of the API (though his example signature mentioned a Converter, too)
> If you have a method:
> Collection<T> getAll() returning a Collection which is in fact backed by a
> LinkedList or another List, why would you lose its order if you cast it to
> a List?
>
> Trying to cast to say a Set would produce a ClassCastException, one could
> check this before trying to cast, but if the underlying type is a List it
> remains a list.
>
> Werner
>
> On Sun, Jan 18, 2015 at 7:27 PM, Mark Struberg <[email protected]> wrote:
>
> > Converters (PropertyAdaptors) do convert the values INSIDE the list. You
> > would not be able to distinguish properly.
> >
> > And casting this to a sorted List makes no sense at all if there are Sets
> > used in PropertySources or anywhere in the Configuration system where you
> > would loose the natural (configured) original order.
> >
> > LieGrue,
> > strub
> >
> > On Sunday, 18 January 2015, 18:31, Romain Manni-Bucau <
> > [email protected]> wrote:
> >
> >
> > >
> > >
> > >Guys we have converters so why do we discuss type?
> > >Are converters not able to handle it? If so we have to update them
> > removing Class for Type...btw we shouldnt have getTargetType but we
> should
> > use reflection to get it and keep api clean IMO. See AnnotationLiteral or
> > TypeLiteral class for samples.
> > >Le 18 janv. 2015 18:28, "Werner Keil" <[email protected]> a écrit :
> > >
> > >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
> > >>> >
> > >>>
> > >>
> > >
> > >
> >
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
