Map sounds more familiar for users IMO and functions it provides can be needed or nice to have - not far from what you explained as well if I got you correctly.
If a Map is accepted as a compromise I'm +1 anyway Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-06 16:08 GMT+01:00 Anatole Tresch <[email protected]>: > 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*
