Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] Element references
Hi Vlad,
 
Perhaps I could be of more help if  you would point me at the specific place in the erlide code base where you feel this issue arises?
 
From your description, the closest thing I can see is ErlangFunction and/or FunctionRef, but each of them seems to have its own semantics with regard to find queries:
 
* ErlangFunction is meant to be used for queries within module (it can specify only name and arity),
and can handle ANY_ARITY
 
* In FunctionRef, function name and module can be regexps (at least, that's what IErlModelCore#findFunction Javadoc says).
 
So they look different enough to warrant their existence. Am I missing something?
 
Best regards,
Vladimir
 
 
Thank you for the feedback, Vladimir.

I don't like having duplicate code, but it's not a huge problem either.

regards,
Vlad


On Mon, Apr 13, 2015 at 9:38 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
Hi Vlad,
 
First, let me emphasize that handles are always precise. I mean there can be no ambiguity of where in the containment tree of the entire model an element represented by a handle is located. Thus, if you need to find an element in the model, the handle representing that element is the search result, so (as you hinted at) there would be completely no sense to use it a search argument.
 
That said, you can still model the element reference as a handle (representing the element reference itself). Its parent would be the source construct containing the reference. Sometimes it makes sense, sometimes it does not.
 
For example, you could, in theory, model the type reference of a variable as a handle whose parent would be the variable declaration and whose name would be the type name as expressed in the source. It would make sense to represent the type reference as a handle if, for example, you needed to show it as a separate element in the outline. In this case you probably don't, so it's probably more effective to simply have a method like String getType() in the variable declaration.
 
I think it really depends on the specific model. You can safely continue to use your reference classes if that's what makes sense to you in your model. There is nothing inherently wrong with that.
 
HTH,
Vladimir
 
 
Hi!

In the model API there will usually be methods like findElement(ref), where ref is an object describing the element. IHandles would be perfect to be used for that purpose, but they can't be created outside the model (i.e. they need to have a parent, and it's basically what the findElement is meant to provide... 

I am currently using separate reference classes, but it doesn't feel completely ok. Is this the way to do it anyway, or is there a trick that I'm missing?

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

Back to the top