Hi Wes, I really like what spring data gemfire has done. I like the fact that you get to create a client side interface for the function as well as defining the method on the server side as you've outlined.
One thing that's slightly different about that approach is that you no longer have a Function interface - you have annotations on arbitrary methods. That meams you can't use a lambda for a function, but I'm not sure if anyone will do that anyway considering how complex the function code tends to be. The way I'm thinking of it, our our existing function execution code is a lower level API on top of which an annotation based API can be constructed. Does that seem reasonable? Or do you think we should drop the RegionFunction/MemberFunction interfaces entirely in favor of an annotation based approach? -Dan On Thu, Dec 17, 2015 at 9:51 AM, Wes Williams <[email protected]> wrote: > These proposals are great. I find convenient the signature matching that > Spring GemFire provides. How difficult would it be to create a late-binding > call to a matching signature based on the argument types for developer > convenience? > > The following is from > http://docs.spring.io/spring-data-gemfire/docs/1.4.4.RELEASE/reference/html/function-annotations.html > > Object[] args = new Object[]{"hello", 123} > > Then the Spring container should be able to bind to any method signature > similar to the following. Let's ignore the return type for the moment: > > public Object method1(String s1, int i2) {...}public Object method2(Map<?,?> > data, String s1, int i2) {...}public Object method3(String s1, Map<?,?>data, > int i2) {...}public Object method4(String s1, Map<?,?> data, Set<?> filter, > int i2) {...}public void method4(String s1, Set<?> filter, int i2, > Region<?,?> data) {...}public void method5(String s1, ResultSender rs, int > i2);public void method6(FunctionContest fc); > > The general rule is that once any additional arguments, i.e., region data > and filter, are resolved the remaining arguments must correspond exactly, > in order and type, to the expected calling parameters. > > *Wes Williams | Pivotal Sr. **Data Engineer* > 781.606.0325 > http://pivotal.io/big-data/pivotal-gemfire > > On Wed, Dec 16, 2015 at 12:27 PM, Dan Smith <[email protected]> wrote: > >> Hi all, >> >> Ashvin, Gester and I have gone over our function execution API, and we >> have >> some proposals for how we should improve the function service API to make >> it a little bit easier to use. Please take a look at the proposals on the >> wiki and let us know what you think: >> >> >> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments >> >> -Dan >> > >
