[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Greetings handly-dev,
Thank you very much for initiating this discussion and for your useful comments and suggestions! I apologize for the delay needed to think this through.
I reverted the commit introducing IModule (unfortunately it had been merged to 'master' just before the discussion started) and have proposed a new solution:
The new design seems cleaner and, hopefully, more sustainable. It solves the original problem, but doesn't introduce additional elements and should be less invasive and more self-consistent.
Please take a look and let me know if you have any concerns or questions.
Thanks,
Vladimir
Hi,
No, I don't think I can override. Or more precisely, I need both methods - some code needs just an IModule, other code needs the ISourceFile, and overriding would require instanceof checks. Some elements are specific to source code (comments, for example) and they would have to either cast the value or declare another method that would confuse things even more (which kind of module is getModule and which one is getErlModule?)
I don't have a good alternative, because each implementation might have different names and structure.
ICodeContainer or ISourceContainer? This level is needed just for making a connection with the resource that contains the code.
IUnit or ICodeUnit or ISourceUnit might work too, as Ondrej suggested, but it collides with the JDT model's ICompilationUnit (which is an ISourceFile).
----
Now, thinking about it, even ISourceElement might not be a very good name either, because IModules need not contain source code. What we really have is a "code model". But maybe we should not go that far! :-)
regards,
Vlad