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.
>
> John
>
>
>
>
>
> From: Eric Moffatt/Ottawa/IBM@IBMCA
> To: E4 Project developer mailing list <[email protected]>,
> Date: 03/04/2013 04:22 PM
> Subject: [e4-dev] E4 Formal API Part 1: Dependency Injection
> Sent by: [email protected]
>
>
>
>
> It's amazing what a week's vacation will do...;-).
>
> I've updated the wiki at http://wiki.eclipse.org/Eclipse4/API/DI to contain
> the current set of API that we expect to formalize within the next couple of
> weeks. I encourage anybody who's interested to go there and check it
> out...especially for things that I may have missed...if it is *not* on that
> page then will won't be API (at least for Kepler).
>
> Comments welcome...
>
> I'll try to get something similar put together for the Mode tomorrow and then
> on to the various services...
> Eric
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
