BTW you always have "functions" to access a datastructure. With a Map you have severals, whereas with Function<String,String> you only have one... but I dont want to start a discussions on the mathematical fundations...
2015-01-06 15:37 GMT+01:00 Romain Manni-Bucau <[email protected]>: > I got your case and I have the same but your solution is not user > friendly and you only need to access currently built configuration > (Map), why abstracting a Map by a function? I mean your contract is > just a data structure access and not a behavior as you explained it so > Function is wrong. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-06 15:29 GMT+01:00 Anatole Tresch <[email protected]>: > > Hi Romain > > > > please reread my last mail. Accessing Configuration reentrantly will not > > work, since you will have to apply the filters before returning asny > > result. Also you will not want to look at the filtered but at the > original > > values... > > Using a function is nothing else than applying the recommendations from > > Oracle to use prebuilt function before defining your own. > > > > According metadata: I did not mention it explicitly, but > > > > - it is a absolutely required core feature for all companies in the > > finance industry, especially banks. > > - it is quite for sure important also for others. > > - it is not built in in the core (we have explicitly removed it), but > is > > modellabe by additional properties: > > > > E.g. a value > > > > a.b.dbPassword=hd8z874h8efh8rth48rheih > > > > could have additional metadata: > > > > a.b.dbPassword[metadata]=sensitive:true,cypher:DES3,issuer=a122334 > > > > If you now want to filter these passwords for users, that are not in the > > admin role you must have access to the seconds property. > > This is an elegant and easy way to provide metadata: > > > > > > - it can be added by a module easily > > - it fits in the current solution > > - it is extendible > > - it can be used for filtering > > - it can be added on top (additionally) by additional property > providers > > - it can be overridden as needed by overriding property sources > similar > > to normal properties > > - it can be filtered out easily > > - ... > > > > Got the point? There is a couple of use case behind these concepts... > > > > Anatole > > > > > > > > > > 2015-01-06 14:41 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > >> you dont want to make it explicit it is the metadata - this term > >> doesnt mean much btw, is it the 'in progress' configuration of the > >> property source key-values? > >> > >> this can make sense but shouldn't rely on a function which really > >> makes no sense in term of API. > >> > >> if you want to "evaluate further properties" you need the > >> Configuration otherwise you just get raw properties which shouldnt be > >> readable with our current contracts IMO. > >> > >> About supports: as said +0. > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-06 14:35 GMT+01:00 Anatole Tresch <[email protected]>: > >> > Hi Romain > >> > /Mark > >> > > >> > > >> > around your proposal my feedback: > >> > > >> > Filter { > >> > boolean supports(key, value); > >> > String filter(key, value); > >> > } > >> > > >> > - 2 methods for something easy like value filtering, IMO too much! The > >> > supports method does not add any additional functionality I cannot do > >> > within filter itself > >> > - There is a very good reason, why there is also a Function coming in > the > >> > API: it gives the filter > >> > access to the original unfiltered set of properties for > >> > - accessing metadata about the property to filter > >> > - to see if in case of a null value read out the original value and > >> maybe > >> > readding a filtered version of it > >> > - evaluate further properties > >> > > >> > Since the time of filtering is a special runtime state within > evaluating > >> > configuration it is not possible to route the call simply to the > normal > >> > configuration methods (it would loop). Additionally original > unfiltered > >> > values are not present. > >> > > >> > So -100 to remove it. Summairzing IMO the filter looks exact how it > >> should, > >> > no more no less. > >> > > >> > Cheers > >> > Anatole > >> > > >> > > >> > > >> > 2015-01-06 12:16 GMT+01:00 Romain Manni-Bucau <[email protected] > >: > >> > > >> >> Hi guys, > >> >> > >> >> just notice filter API was: > >> >> > >> >> String filterProperty(String key, String valueToBeFiltered, > >> >> Function<String,String> propertyValueProvider); > >> >> > >> >> I dont get it at all: > >> >> 1) if forces a returned value -> I'd add a supports(key, > currentValue) > >> >> to make filter composition easier > >> >> 2) why a function? a filter needs key and value not only one of both > + > >> >> why doing a function (filterProperty) of function since we dont need > >> >> it for something as trivial as filtering. If you want to play with > >> >> java 8 then org.apache.tamaya.core.internal.DefaultConfiguration# > >> >> get(String) > >> >> should get a list of fnuction to apply but it would be a very weird > >> >> API. > >> >> > >> >> My Proposal would be simply: > >> >> > >> >> Filter { > >> >> boolean supports(key, value); > >> >> String filter(key, value); > >> >> } > >> >> > >> >> > >> >> wdyt? > >> >> > >> >> > >> >> Romain Manni-Bucau > >> >> @rmannibucau > >> >> http://www.tomitribe.com > >> >> http://rmannibucau.wordpress.com > >> >> https://github.com/rmannibucau > >> >> > >> > > >> > > >> > > >> > -- > >> > *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>* > >> > > > > > > > > -- > > *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* > -- *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*
