Hi all,
A minor development question. In the merge template rules, before adding a marker, we check to see if the types have been defined for the fields of the template (as we need this information into to add formal parameters). Therefore, if one of the field types isn't defined then these potentially merge-able templates are ignored.
We have 3 options
a) continue exactly as we are already and just ignore them b) continue to ignore the potential merge, but add an error marker to indicate that the type hasn't been defined for that template field c) add a marker in the usual way to point out the potential merge and just fall-back to the error message that is displayed when the user tries to perform the refactoring (I have always had the same check for field type definitions in checkInitialConditions() in the merge processor).
b) may be preferable but then it may give the false idea to the user that these highlighted types are the only ones that are not defined in the project (i.e. we would really need to be adding errors for all undefined types that are used.
Thoughts?
Regards, Dominic
Hello Dominic,
Dominic Evans wrote:
We have 3 options
a) continue exactly as we are already and just ignore them b) continue to ignore the potential merge, but add an error marker to indicate that the type hasn't been defined for that template field c) add a marker in the usual way to point out the potential merge and just fall-back to the error message that is displayed when the user tries to perform the refactoring (I have always had the same check for field type definitions in checkInitialConditions() in the merge processor).
I discussed this briefly with Helmut we think that we should stay with solution a). The reason is simple: we are planning to do a (more or less) full semantical analysis including type checks etc. at some point (for 0.7.0 or something like that). At that moment we would have duplicate markers if we would choose solution b). As you already said, the solution b) would be incomplete anyway and i think it is better to avoid scattered partial checks everywhere just because they are possible or easy.
trex-devel@informatik.uni-goettingen.de