Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] IModule
I think you will have to explain it a little bit :-)
 
I should probably add that there are actually two related decisions
in the newly proposed design:
 
1. Source elements now don't have a getSourceFile() method or the like
to get at their corresponding "module". Such method, if necessary or desired,
can be provided by model implementor, probably in model-specific terms.
In Handly itself, there are currently a couple of places (only)
where a similar functionality is required:
 
* SourceConstruct#getOpenableParent() -- default implementation now returns
the first ancestor that is not ISourceConstruct (previously it returned
the source file). Strictly speaking, there is no guarantee that the returned
element is necessarily a "module" (whatever it might be), but then it is not
required by the contract of the method (it needs the first "openable" ancestor,
not the "module" per se). Besides, this default implementation can always be
overriden by model implementor if necessary. So not a big deal probably.
 
* SourceElementUtil#getElementAt(ISourceElement element, int position)
previously received a source file as the first argument and reconciled it
before requesting the source element at the given position. Now it checks
whether the given element is a source file or has a source file as its
ancestor, and if so, it will reconcile the source file.
 
2. There is no "root interface" for "modules" (such as the previously proposed
IModule). We have no sufficient evidence yet whether such a common interface
would necessarily be required. We can always introduce it when/if the need
clearly arises, hopefully even without breaking backwards compatibility.
 
Best regards,
Vladimir
 
Hi Vladimir,

I think you will have to explain it a little bit :-)

If I understand correctly, the "binary file" classes are supposed to inherit directly from ISourceElement, right? 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 :-)

I think it looks good, but it's a bit difficult to be 100% sure until I try to implement it.

regards,
Vlad


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 


On Fri, Mar 13, 2015 at 2:37 PM, Vladimir Piskarev <pisv@xxxxx> wrote:
Hi Vlad,
 
I wonder, couldn't you just override the return type of the getModule method (i.e. use a covariant return type), assuming that erlide modules would extend IModule?
 
I was thinking about a good name for a while, before IModule came to mind. I'm not saying the name cannot be changed, but I'm in lack of a good alternative... I realize that such generic term as "module" can cause ambiguities, but ISourceModule would not be quite correct, since the concept was introduced specifically to allow for "binary modules" (e.g. "IClassFile extend ISourceModule" would look a bit bogus IMO). Before IModule, I was agonizing around something like ISourceHost, which is abstract enough, but seems a bit ugly.
 
Any suggestions for a better name?
 
Thanks,
Vladimir
 
 
Hi!

I have a small problem with the new IModule, that I didn't realize it would be a problem... 

In Erlang, the unit of modularity is a module and my elements had a getModule method. Now This collides with ISourceElement's method and I have to rename it to getErlModule, which is not so nice because all other API doesn't have the "Erl" particle.

I realize it is a bit late to complain and suggest to rename it to ISourceModule or something similar, but I'll do it anyway :-)

best 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


_______________________________________________
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