viatra / EMF-IncQuery

This repository is only kept for historic reasons. All development happens on eclipse.org
http://eclipse.org/viatra
13 stars 4 forks source link

remove all magic strings from generated classes #186

Closed abelhegedus closed 11 years ago

abelhegedus commented 12 years ago

Parameter names, pattern names, pattern FQNs are currently generated into the source code as strings in the proper places. It may increase code quality if we generated constants instead and use these in each occurrence.

This is a personal opinion, this issue is at first only a platform for discussion (hence no assignee).

istvanrath commented 12 years ago

The question is, how does "client code" use such pattern names, FQNs, etc? Is there a HOWTO on using the "generic" IncQuery API?

abelhegedus commented 12 years ago

Currently, there is a "parameterNames" array generated for each Match class, accessed through a simple method:

private static String[] parameterNames = {"CLE", "Task"};

public String[] parameterNames() {
 return ChecklistEntryTaskCorrespondenceMatch.parameterNames; 
}

There are three other methods which use parameter names and one that returns the name of the pattern. Each of these methods use simple strings instead of a common constant.

I think the client code can be split into two categories:

  1. The client knows the Match(er) class, and uses the generated methods (e.g. match.getSomeParameter()). In this case the user also has access to the constants, although they are not needed.
  2. The client doesn't know the Match(er) class, and uses generic methods (e.g. match.getParameter("SomeParameter")). In this cases the constants are not known either.

So, from the client's perspective, introducing constants may not provide any plus in the trivial cases.

I don't think there is a specific HOWTO on the generic API, there are some bits and pieces in the school and headless examples, but those don't deal with match objects in particular.

istvanrath commented 12 years ago

So if there is no advantage on the client code side, what's the point of this ticket? :)

Btw, the HOWTO on using the generic API is a must-have for 0.6.

abelhegedus commented 12 years ago

As mentioned, I created the ticket to inspire discussion (not to generate further TODOs :D)

If others have no opinion in the matter, we can close the ticket (or change it to "create howto for generic API).

abelhegedus commented 11 years ago

Not really an issue, won't fix.