Re: [handly-dev] Proposed API change: IModule

[Vlad Dumitrescu <vladdu55@xxxxxxxxx>]

Hi!

On Mon, Mar 2, 2015 at 9:56 AM, Vladimir Piskarev <pisv@xxxxx> wrote:

> 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.

That sounds very reasonable, and I absolutely agree with you in general, but I'm not sure I understood the specifics completely. In particular, this part: "if we get constrained to a single type hierarchy there will be code duplication". Could you please elaborate a bit more on it?

/ IMO, "the containment of model elements and the logic of where each element gets its contents" are already separated in Handly. You could use different "structure builders" to assemble pretty much the same elements (e.g. IType, IField and IMethod) in a containment tree of various "openables" (such as ICompilationUnit and IClassFile) /

I think I'm still influenced by the "old-style" model I'm trying to get rid of. i think you are right, there might not be that much duplication (and the specific model implementation can make sure it is minimal).

But I still have a feeling that something is off... 

Is ISourceConstruct.getSourceFile really necessary anymore? All uses of it are in order to call getSourceElement, which now takes an IModule. 

I'm unsure about SourceElementUtil.getSourceElement and SourceElement.getElementAt: the 'position' argument might not be relevant for IModules that aren't shown in textual buffers (but still show an outline linked to the current selection). But maybe that problem should be left for when some client comes with that requirement, as it's difficult to guess what that could be.

best regards,

Vlad