[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] E4 Formal API Part 1: Dependency Injection
|
>
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?
If possible we should allow Java 8 syntax in Eclipse 4 API. The new function parameters will help to reduce the customer code further which IMHO is one of the big themes of Eclipse 4.
Best regards, Lars
2013/3/6 John Arthorne
<John_Arthorne@xxxxxxxxxx>
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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
