Community
Participate
Working Groups
Currently, almost all of the interfaces in o.e.handly.model package are marked with @noimplement, with the single (partial) implementation supplied in o.e.handly.model.impl. However, there might be cases where allowing for alternative client implementations would be really useful. In particular, clients might implement Handly model API on top of existing handle-based models (see bug 473394 for an example of such model adaptation).
Of course, the reason for the @noimplement constraint is that it facilitates interface evolution: we can define new methods in the interface. If we were to remove this constraint, we would have to come up with some alternative means for interface evolution: * extension interfaces (quite ugly) * complete "mini-implementations" of the interfaces that clients should extend (no multiple inheritance, locks clients into the provided class hierarchy) * default interface methods (seems to be the best solution, but requires Java 8)
It seems the best we can do without default methods is to provide the "mini-implementations" for all methods of the core handle interfaces in a single class that clients would extend and implement the necessary interfaces as they see fit: https://github.com/pisv/handly-playground/blob/simpleimpl/org.eclipse.handly/src/org/eclipse/handly/model/impl/simple/ProtoHandle.java
Effectively fixed via bug 491564.
