>>he 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?<< Exactly.
>>Or do you think we should drop the RegionFunction/MemberFunction interfaces entirely in favor of an annotation based approach?<< My preference is to do both. Here are my reasons: When I do GemFire POC's, a top priority is to write code in such a way that it conveys simplicity and understandability to the new customer. If I were to adopt an opinionated style for POC's that I do, I opt for the @Annotation style. However, some developers prefer writing code with a lower-level style similar to writing compilers and stacks (e.g. an argument list). I wonder if removing it creates trouble for the system-level function style already in GemFire and possibly breaks backwards compatibility. If an @Annotation style could pre-compile and cache the method metadata and the function interface hands it to a statically-typed method, I would use that style all day long when presenting to customers. *Wes Williams | Pivotal Sr. **Data Engineer* 781.606.0325 http://pivotal.io/big-data/pivotal-gemfire On Thu, Dec 17, 2015 at 6:09 PM, Dan Smith <[email protected]> wrote: > 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 >>> >> >> >
