@Constraint location argument, why a String?

[Joost van Pinxten]

The constraint annotation uses a string as the argument for the location, but I don't see any reference to why this is. The hint says that it should contain the name of one of the parameters. Why is this not an actual reference to one of the declared parameters? It seems that you could catch typo's more easily that way (and automatic refactoring could potentially provide better results).

So, is there a use of this location argument that I'm missing? Or is this perhaps a placeholder for future functionality?

[Ujhelyi Zoltán]

Hi,

you are right, it should be a variable reference instead of a string. However, the functionality was implemented before the support for variable references in annotation parameters, and we did not change the annotation definition after for backward compatibility.

However, it would make sense to change this - we will weigh the pro and cons yet again.

Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

> --
> You received this message because you are subscribed to the Google Groups "EMF-IncQuery Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to incquery-user...@googlegroups.com.
> To post to this group, send email to incquer...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msg/incquery-users/-/-9nJlTSun4MJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ábel Hegedüs]

Hi,

the location argument is used in the generated constraint class and is used for exactly what the name implies. The EObject in the given match parameter will get the marker if the constraint is violated. This allows you to navigate to the element in many editors by double-clicking the marker.

It is a string mainly for legacy reasons, the annotation was created before direct reference to parameters were allowed in annotation parameters.

You can post a bug report on BugZilla if you believe that it would be important to change it to direct reference.

Finally, the validator does check that it is a valid parameter name (if it doesn't that's a bug that should also be reported), and refactoring of pattern and parameter names doesn't work too well at the moment anyway.

(I see that Zoltán already answered, but decided that you might like to get some further details)

Best regards,

   Ábel

____

http://about.me/abelhegedus/bio

On 29 January 2013 16:58, Joost van Pinxten via EMF-IncQuery Users <incquery-users+noreply-APn2wQeyh...@googlegroups.com> wrote:

The constraint annotation uses a string as the argument for the location, but I don't see any reference to why this is. The hint says that it should contain the name of one of the parameters. Why is this not an actual reference to one of the declared parameters? It seems that you could catch typo's more easily that way (and automatic refactoring could potentially provide better results).

So, is there a use of this location argument that I'm missing? Or is this perhaps a placeholder for future functionality?

--

[Joost van Pinxten]

Hi,

Op dinsdag 29 januari 2013 17:07:17 UTC+1 schreef Ábel Hegedüs het volgende:

Hi,

the location argument is used in the generated constraint class and is used for exactly what the name implies. The EObject in the given match parameter will get the marker if the constraint is violated. This allows you to navigate to the element in many editors by double-clicking the marker.

It is a string mainly for legacy reasons, the annotation was created before direct reference to parameters were allowed in annotation parameters.

I figured as much.

You can post a bug report on BugZilla if you believe that it would be important to change it to direct reference.

 
It's not a dealbreaker, but what are your thoughts on this: is it better to use only strings in annotations (for consistency), or is it better to do direct references (as then code completion and quick fixes become easier?)

 

Finally, the validator does check that it is a valid parameter name (if it doesn't that's a bug that should also be reported), and refactoring of pattern and parameter names doesn't work too well at the moment anyway.

Missed that, sorry, it does indeed validate the name. And the refactoring is mostly broken indeed ;-)
 

(I see that Zoltán already answered, but decided that you might like to get some further details)

Best regards,

   Ábel

____

http://about.me/abelhegedus/bio

[Ábel Hegedüs]

On 30 January 2013 14:01, Joost van Pinxten via EMF-IncQuery Users <incquery-users+noreply-APn2wQeyh...@googlegroups.com> wrote:

 
It's not a dealbreaker, but what are your thoughts on this: is it better to use only strings in annotations (for consistency), or is it better to do direct references (as then code completion and quick fixes become easier?)

 

 If you define a new annotation, in my opinion it is better to use direct references, if the value MUST be a parameter. This makes it easier to write an annotation validator (you don't need to check that the value is correct), and to process the annotation from code (you can retrieve the Parameter and Variable directly, without having to go through the parameter list based on a string value).

Similarly, you can use set the parameter type to number or boolean as well, if that's appropriate for the parameter and use simple string only when the other types are not applicable.

[Istvan Rath]

I submitted a bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=399491

Istvan

--
You received this message because you are subscribed to the Google Groups "EMF-IncQuery Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to incquery-user...@googlegroups.com.
To post to this group, send email to incquer...@googlegroups.com.