> 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 <[email protected]> > 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 > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
