| Re: [e4-dev] E4 Formal API Part 1: Dependency Injection |
| Re: IContextFunction The nice thing about the abstract ContextFunction class is being able to change/add to method signatures and forward old signatures to the new signatures. For example, to expand the compute(IEclipseContext) to include the requested context key is easy with no API breakage. And would changing ICF to be SAM-able work in practice? The typical use would be for use with IEclipseContext.set(String key, Object value), where the value is an Object. But as long as we change the ICF method signature before we do this, then I'm definitely happy to toss the class and keep only IContextFunction. I'm −1 to runAndTrack taking an IContextFunction as RATs don't return a value. Seems like an overload of ICF. But having a RAT be a SAM type could be a good thing. Brian. On 5-Mar-2013, at 9:30 AM, John Arthorne wrote: We had a brief offline discussion about making our API ready to play well with Java 8 closures. It looks like the current draft state is that any API *interface* with a single abstract method ("SAM type") can be used with the closure syntax. For IContextFunction/ContextFunction I might have leaned towards an abstract class in the past because it would enable us to extend it in the future, but in this case I think closure compatibility is more valuable so I propose we just have IContextFunction. A function object is about the most perfect example of a type that should be able to use closure syntax. RunAndTrack would be another candidate to make into a SAM type although that change would be more disruptive. The method RunAndTrack#runExternalCode could be a static helper declared elsewhere. Without that RunAndTrack could actually just be replaced with IContextFunction. |