A tiny bit of punctuation would help: foo.pas:42: Capitalization of identifier "<current>" doesn't match original one. foo.pas:17: The original capitalization is "<original>".
Well, most other errors don't include puncutation, and no complete sentences. So it would be unsystematic to make this one different.
Sigh. Maybe it's time to start making them more clear? If not, how about:
foo.pas:42: capitalization of identifier "<current>" doesn't match original one foo.pas:17: the original capitalization is "<original>"
The quote marks would help.
Note that I substituted 'original' throughout for clarity. (Surely you don't mean the *previous* one - the one that just preceeded? In that case it would yell for the third item in this series: Knifefish ... KnifeFish ... Knifefish. I would think it should only object to the second one.)
No, sorry. Storing *all* capitalisations is extra effort. Since someone who uses this warning is supposed to want uniform capitalisation, I don't think the effort is worth it ...
No, I thought that you would only store the first one ("original") and compare all later ones ("current") to that. Generally the first one is the definition, so this should work fine. In this case it WOULD only object to the second case. If, on the other hand, you store the PREVIOUS one, it would object to both the second KnifeFish AND the third Knifefish, even though that matches the original (first) definition. That could be rather confusing to someone. ("Why is it yelling at me for this one? It's right!")
Hmm. I just realized that there is a question of scope here. Are you making a pushdown stack for this?
var Knifefish ...
procedure capture; var KnifeFish ... begin ... end;
It should not object to this case.
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/
Tom Schneider wrote:
A tiny bit of punctuation would help: foo.pas:42: Capitalization of identifier "<current>" doesn't match original one. foo.pas:17: The original capitalization is "<original>".
Well, most other errors don't include puncutation, and no complete sentences. So it would be unsystematic to make this one different.
Sigh. Maybe it's time to start making them more clear?
I personally don't mind either way. Before you start doing those changes, I suggest you contact the GCC developers since many messages are in the backend and changing only the frontend ones would be unsystematic as well ...
If not, how about:
foo.pas:42: capitalization of identifier "<current>" doesn't match original one foo.pas:17: the original capitalization is "<original>"
The quote marks would help.
As you may have noticed, identifiers in messages are always enclosed in `...'.
Note that I substituted 'original' throughout for clarity. (Surely you don't mean the *previous* one - the one that just preceeded? In that case it would yell for the third item in this series: Knifefish ... KnifeFish ... Knifefish. I would think it should only object to the second one.)
No, sorry. Storing *all* capitalisations is extra effort. Since someone who uses this warning is supposed to want uniform capitalisation, I don't think the effort is worth it ...
No, I thought that you would only store the first one ("original") and compare all later ones ("current") to that. Generally the first one is the definition, so this should work fine.
As I said, if you use this warning, generally you'd want to write them all the same, and any deviation is a mistake. Until you convince me otherwise, I don't see why a mistake would be less likely to occur in the definition than in an applied occurrence.
In this case it WOULD only object to the second case. If, on the other hand, you store the PREVIOUS one, it would object to both the second KnifeFish AND the third Knifefish, even though that matches the original (first) definition. That could be rather confusing to someone. ("Why is it yelling at me for this one? It's right!")
OTOH, if you do make a mistake in the definition, you'd get messages for each applied occurrence which could be very many. In the other case, it's at least limited to two messages ...
Hmm. I just realized that there is a question of scope here. Are you making a pushdown stack for this?
I've replied to this already, see http://gnu-pascal.de/crystal/gpc/en/mail7661.html
Frank
-
Frank Heckenbach -
Tom Schneider