Brian de Alwis wrote on 03/06/2013 09:32:48 AM:
> 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.
Yes I agree it is always going to be a trade-off between flexibility to
evolve the API versus ease of use. It's tempting in this case because this
"function object" is exactly what lambda expressions are designed for. It
is not a massive improvement, but we do have quite a large number of
anonymous subclasses of ContextFunction today. The most common example is
a lazy initializer, which would look like this:
IContextFunction func = (context) -> {
if (editorRegistry == null) {
editorRegistry = new EditorRegistry();
}
return editorRegistry;
};
context.set(IEditorRegistry.class.getName(), func);
> 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.
It works if you declare the function variable first like the above. If you
wanted to inline the entire function we would need to add
IEclipseContext.set(String, IContextFunction).
> 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.
What change are you referring to here.. is it to pass in the request key
to the ICF.compute method?
I wonder if a middle ground would be to keep both the class and interface,
and EclipseContext implementation could downcast ICF to CF if more
advanced methods are supported in the future. I.e., enable lambda
expressions for the large number of simple cases, but provide a class with
more complex capabilities for the rare cases that need it.
>
> 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.
Fair enough. I remember we had runAndTrack(java.lang.Runnable) in the
past, which could be added back to streamline the simple cases. And just
to make sure we get our terminology straight, it looks like "SAM Type" is
now being called "Functional Interface" (presumably to make it clear
abstract classes are not allowed).
Lars, Tom and others, do you have an opinion on the value of enabling
clients to use Java 8 syntax here, or in other parts of Eclipse 4 API?
John
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
