Community
Participate
Working Groups
It would make some parts of the databinding framework more convenient to use if lambda expressions could be used directly for IConverters. ### Example var s = new UpdateValueStrategy<Integer, String>(); // Like this: s.setConverter(i -> "int: " + i); // Instead of this: s.setConverter(IConverter.create(i -> "int: " + i)); ### Implementation This can be achieved by providing default implementations for the methods IConverter.getFromType and IConverter.getToType. The only remaining unimplemented method would be IConverter.convert, which would make it possible to implement a converter with a lambda. ### Disadvantages To do this the API annotations @noextend and @noimplement would need to be removed from IConverter, opening up the type for direct implementation by clients. This makes it a little harder to make additions to the IConverter in the future. This seem to be a small problem however, which is more than enough balanced by the benefits of the change. This is because modern Java versions have the default method construct, and also that IConverter is a stable interface which is unlikely to be changed in the future.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/189215
Christoph Laeubrich wrote in the Gerrit change: (https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/189215) > I wonder if from/to are really used anywhere if they could return null it seems a bit useless. They don't seem to be really used in the framework itself... I think maybe the intention was that you could have a value of unknown type, then find the right comparator from its from-type and to-type. > Beside that they should probably better return Class<..> types instead of object? The type in the framework, for converters, observables and properties all use Object. That is because EMF uses EClassifier and related types instead of Class. The intention was that the databinding component should support EMF and other related frameworks.
