Closed abelhegedus closed 11 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?
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:
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.
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.
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).
Not really an issue, won't fix.
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).