Hi Romain/all I think we have quite a common agreement on the basic functions designed so far and I do not want to reinvent or change any of the basic mechanism. I simply come up with a simple request to use the algorithm pattern for a small subset of a functionality (how the final property value is evaluated). The usage of TypeLiteral was even your own proposal AFAIK, when we discussed PropertyConverters ;) ).
Our current configuration model in general IMO is a very good start. It is already so flexible that I can implement 60-70% of use cases I have currently in use within Credit Suisse (this is somehow my "benchmark", which from my discussions I had during the last years covers a majority of use cases when dealing with distributed and modular systems). I am sure you remember, we had a discussion on another mail thread yesterday about Collection support. My proposal basically is the outcome of having played around to extend our API to support collections based only on Map<String,String> only as internal PropertySource representation thus avoiding the String[] getListProperty(String) methods. So for getting type information and define the content type of collections we need TypeLiterals, which similarly is useful perhaps for other non collection cases. Since collection entries can be defined in different property sources, a final list may want to contain all the properties found, instead of overriding, so values of different property sources are to be combined. AFAIK you already agreed on that UC. Hardcoding yet another strategy IMO makes no sense, so I would recommend use the default for all common aspects (that is what we already have in place) and add support for adapting the default where it is not appropriate. Thinking on this IMO both aspects (TypeLiterals and the collector) are the same for evaluating single property values as well, so regarding that it makes no sense to model collections differently, but extend/flexibilize the way how we can access properties in general. I tried to combine both aspects in one class, which I called PropertyQuery. Perhaps also the name PropertyQuery is confusing. Alternates would be PropertyRequest, PropertyAccess,... or whatever you like, I am completely open here ;) We can postpone that discussion, but just stopping this discussion now will not solve anything. Also we already invested a lot of discussing collection support, why stop here. We have enough time I think. We have important use cases to solve that may affect the Configuration interface as a whole. Adding them later may be a bad idea, so we should sort out these things now IMO. So I am curious to see your concrete (improvement) proposals ;), so we can continue to see, if we end up in a common view. If so, others on the mailing list also have a chance to join us again, I think. Anatole -----Original Message----- From: Romain Manni-Bucau [mailto:[email protected]] Sent: Donnerstag, 22. Januar 2015 09:45 To: [email protected] Subject: Re: PropertyQuery not exactly, it is different to expose MapReduce in API and to implement it behind another concept, ATM it is an implementation detail. Why I worry a bit about Query stuff is we start to leave configuration layer to enter backend one, not sure it does worth it *to start* - I understand your feature even if I never needed it but I'd really like we ensure our basis are solid enough before adding features on top of them. Said otherwise I think we should now focus on trying to make a 0.1 - we can add alpha to make obvious we are not done - and stop adding anything before being fully agree on all we have. Does it make sense? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-22 9:39 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Romain > > About lamba friendly I can still have a Builder that creates a query. Works > perfectly. > The default use cases would remain as is. Queries would just add about 3 > methods to Configuration. We get as well all the flexibility we would need > for collection support as well ;) > > Mapreduce? Well what else is evaluating a chain of propsources by > overridding? Its already there, but hardcoded the same, which is obviously > not flexible enough! > > - > Anatole Tresch > Glärnischweg 10 > 8620 Wetzikon > Tel +41 (43) 317 05 30 > - > Send from Mobile > >> Am 22.01.2015 um 09:11 schrieb Romain Manni-Bucau <[email protected]>: >> >> isnt it too complicated for most common use cases (+ not that lambda >> friendly cause of the 4 parameters which dont help writing readable >> code IMO). >> >> Functionally it works but it makes default cases "hard" and actually >> you just want to implement the MapReduce pattern so maybe we should >> call it this way if we go this way. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-22 8:44 GMT+01:00 Anatole Tresch <[email protected]>: >>> Dear all >>> >>> *let's think about additional use cases:* >>> 1) as mentioned in my last mail about collection types,* overriding may not >>> always be the right resolution policy *for accessing a configured value >>> (e.g. for collecting all configured values in a final set/list). >>> 2) sometimes I want to define my own PropertyConverters (already >>> implemented) >>> 3) sometimes I even would like to evaluate multiple keys taking the result >>> of the first property key that returns a config property (nice convenience) >>> >>> When we will add all this kind of aspect into Configuration, we will end up >>> in a messy interface, e.g. for >>> String get(String); >>> <T> T get(String, Class<T>); >>> <T> T get(String, Class<T>, PropertyConverter); >>> >>> String get(String, ValueCollector); >>> <T> T get(String, Class<T>, ValueCollector); >>> <T> T get(String, Class<T>, PropertyConverter, ValueCollector); >>> ... >>> >>> Obviously that does not make sense. >>> >>> Instead of I would propose, we would define a PropertyQuery, which >>> basically is >>> >>> - is the same as a TypeLiteral<T> solving the type aspects >>> - has a list of *keys* to be evaluated, at least one >>> - optionally has a ValueCollector >>> - optionally has a list of PropertyConverter >>> >>> With that our interface gets much leaner, but still flexible enough to >>> accommodate the use cases above: >>> >>> String get(String); >>> <T> T get(String, Class<T>); >>> <T> T get(String, Class<T>, PropertyConverter); // may be ommitted as well ? >>> <T> get(PropertyQuery<T> query); >>> ... >>> >>> This solves all use cases above and gives us an easy way to add additional >>> feature, if needed (I dont see any, but who knows). Hereby ValueCollector >>> would be defined as follows: >>> >>> @FunctionalInterface >>> public interface ValueCollector { >>> >>> /** >>> * Method that is called for each value returned by a PropertySource >>> for the given key. >>> * @param currentValue the current value, including null. >>> * The collector should either combine the existing >>> value with value from {@code currentValue} >>> * or replace the value in {@code currentValue} >>> with {@code valueRead}, hereby returning the >>> * result to be used as new {@code currentValue}. >>> * @param key The current key to be evaluated. >>> * @param newValue the new value read from the current {@code >>> propertySource}, not null. >>> * @param propertySource The PropertySource that returned the current >>> value (either as the result of a direct >>> * access of as a property Map containing the >>> given key. The PropertySource given >>> * may be evaluated for additional meta-data, how >>> the given values are to be combined. >>> * @return the value to be used for future evaluation. >>> */ >>> String collect(String key, String newValue, PropertySource >>> propertySource, >>> String currentValue); >>> >>> /** >>> * Default overriding collector. >>> */ >>> public final ValueCollector DEFAULT_OVERRIDING_COLLECTOR = (k, nv, ps, >>> cv) -> nv; >>> } >>> >>> Feedback? >>> >>> Cheers, >>> Anatole
