[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[handly-dev] Proposed API change: IModule
|
Hi,
I'd like to open a discussion on a proposed API change in Handly 0.3: introducing a new interface, IModule, which will extend ISourceElement and will, in turn, be extended by ISourceFile.
This is inspired by the sudden realization that Handly, in its current form, is not suitable for models like the JDT Java model that describe (the contents of) "binary modules" in roughly the same terms as "source modules".
In Java model, both ICompilationUnit and IClassFile consist of pretty much the same elements: ITypes, IMethods and IFields. The interface ITypeRoot is the common protocol for ICompilationUnit and IClassFile. It is important to note that, unlike a compilation unit, a class file can have or not to have a corresponding workspace file (for example, it may reside in a jar file outside the workspace).
In Handly, ISourceElements must be contained in a ISourceFile that is located in the Eclipse workspace (ISourceElement#getSourceFile and ISourceFile#getFile never return null according to their contracts). This makes it impossible to implement discussed models with Handly.
I think this design flaw should be addressed as early as possible, i.e. in Handly 0.3.
To that end, I propose a new interface, IModule, which will roughly correspond to ITypeRoot in JDT. IModule will extend ISourceElement, and will be extended by ISourceFile.
ISourceElement will get a new method #getModule() that never returns null. The contract of the existing #getSourceFile() method will be relaxed to allow null as return value (note that this is a breaking change, but as far as I can tell it should present no real issues to existing adopters; it may be a problem only for some generic code like the new Handly outline framework that has to deal with arbitrary source elements and can no more assume they always come from a source file).
Apart from the aforementioned breaking contract change, the proposed design retains backwards compatibility.
I have pushed the initial implementation to Gerrit code review:
Please take a look and let me know if you have any concerns or questions. Thank you!
Best regards,
Vladimir
