Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] Element references

Hi,

Yes, these are the reference classes. I wanted to try to collapse all of them into one, and then the result looked a lot like a handle, so that's where the original question came from.

Since I am reimplementing everything based on Handly, there are these other related parts that could also be reviewed. The big problem is that in the old model, an element was the whole thing and one needed a lot of findXXX methods to search for the right object. Now handles are values and can just be created, and instead of checking if an element is null we check if it exists. This affects APIs and semantics. It takes a while until I get my head around how using handles affects everything and sometimes I need confirmation that I'm on the right track or that I'm not missing some detail.

Thanks!
regards,
Vlad


On Tue, Apr 14, 2015 at 9:05 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
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


_______________________________________________
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