[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Vlad,
Thank you very much for your thoughful feedback!
If I understand correctly, the "binary file" classes are supposed to inherit directly from ISourceElement, right?
Correct, at least for the time being. Although probably not a final say on "other modules support", it should provide a path for future evolution, without artificially constraining implementors at present. That's the point.
The price is that there is no place where to put common functionality that would apply to any "source container", but we really don't know if there is going to be some significant such functionality and it's better to keep it simple to start with. There's always a version 2.0 to do such things in :-)
Absolutely! I'm a big believer in "organic growth" :-) Also, I have a gut feeling that "if you can't name it, you don't understand it". IModule and suggested alternatives don't look like particularly good names. So, I cheated a little and tried to avoid drastic design changes until a better understanding is gained.
I think it looks good, but it's a bit difficult to be 100% sure until I try to implement it.
Of course! It seems relatively safe to push it to master, so that we could arrange an I-build for you to try.
Thanks,
Vladimir
On Tue, Mar 17, 2015 at 8:54 AM, Vladimir Piskarev
<pisv@xxxxx> wrote:
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
_______________________________________________
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
