Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] Proposed API change: IModule
Hi!

This looks nice, but there is something that I'm not sure I understand. I feel that there have to be more things added so that it will work as expected (by me, at least).

This is my understanding (in a somewhat loose brain dump): 

"Binary modules" should inherit from IModule (siblings of ISourceFile). These might not have an IResource as base, but maybe an InputStream (to cover most possible cases). Or one could implement an extension to the Eclipse file system EFS that allows handling archives and similar stuff as regular resources. I believe this would be the cleanest solution, but it's quite a big thing to require such an implementation from each model implementor.

Each module can be linked to the source code (that might be a file that is not part of the workspace either, or might even be virtual, decompiled from the binary) and/or documentation. A complete implementation of the model will be able to decompile the contents and show it as text (read only), with all support in the UI (syntax highlighting, navigation, hover documentation). A lot of things will be common between generic modules and SourceFiles: the model underneath them is the same and both will have some kind of document that the UI displays.

My feeling is that it would be easier to use composition instead of inheritance here. There are two different independent axes (the containment of model elements and the logic of where each element gets its contents) and if we get constrained to a single type hierarchy there will be code duplication. Composition allows combining the required parts as needed.

I can't say where Handly should draw the line where its scope ends, but I think the main message is that it shouldn't create artificial limits for implementors.

Regarding the time frame to address this, I agree that sooner is better. Since the version is still 0.x, it would be allowed to make even incompatible changes, if the result is significantly better. As a user of a 0.x framework, I have already accepted this risk - it's better than having to live with ugly warts for a long time.

best regards,
Vlad


On Fri, Feb 27, 2015 at 3:35 PM, Vladimir Piskarev <pisv@xxxxx> wrote:
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

_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev

Back to the top