On Sat, Sep 11, 2004 at 08:02:15PM +0200, Frank Heckenbach wrote:
Waldek Hebisch wrote:
I belive that capitalization is meaningfull for people.
I don't really. In natural language, capitalization is used as a help in reading (used differently in different languages), but it does not carry meaning itself (e.g., a text written in all-caps still has the same meaning).
So it is natural that different meanings needs different capitalizations. Of course, some persons may wish warning for re-using an identifier with different meaning (or as compromise, a warning when meaning is different enough to require different capitalization :)). But IMHO the main use of `-Widentifier-case' is to ensure that standard (case insensitive) interpretation coincides with case sensitive one.
Waldek continued to write, but Frank didn't quote this part:
... And for _that_ purpose current behaviour is defective (gives spurious warnings).
And I must say, I agree with Waldek. I think Frank may have misunderstood Waldek's argument. Let me try to explain why I feel that current behavior is not appropriate.
I recently recompiled a project containing some seven thousand lines of Pascal code distributed over some twenty units. A couple of years ago when it was last compiled, gpc didn't have the identifier-case checking feature. During the recent recompile, I was overwhelmed with casing complaints. Some of them were legitimate: same variable referred to by different casings. And I changed the source accordingly. But many warnings were completely unexpected for me, and unwarranted.
Consider the following situation. I have a record type Event, with a Integer field sc, holding a score. The identifier sc is meaningful only within the scope of the record. It is a local identifier. Obviously (to me), all references to this field would best be done by the spelling sc, and not Sc, or sC, or SC. The warnings keep me honest (thank you!).
But I also have a procedure that has a local variable called SC of type ScoreCard. Again, this is a local name, only meaningful within the scope of the procedure. In fact, it could have been someone else who decided on that name, someone unaware of the record Event with a field sc. It is a local variable in a local name scope. But gpc warns about the casing of SC being inconsistent, because it remembers the casing of the field sc. At least, so it seems to me.
That does not sound right to me. These are two completely different name scopes, where different casings may be called for. I would hope that the casing is for me to decide, and I don't want a warning from the compiler. It is almost as bad as warning me that I have two procedures that use the same name, such as i, for a local variable. In fact, it may be even worse to use case-identical names for entities that are actually very different. (Think of
var i: Integer; { index in array a } versus var i: Real; { imaginary part of approximation of smallest zero of f }
But that is a different issue. You could also warn me when using names that are nearly equal, such Block and Blok, for different entities.
So, the behavior that I had expected from gpc when it comes to identifier case checking is that names that refer to the SAME entity (hence, within the same scope) are checked to have the same casing, warning me if they are not. Of course, such identifiers must be equal modulo case differences, for otherwise they would not refer to the same entity according to the rules of Pascal.
It is another matter, what it would take to make gpc behave this way. But I would think, that it should be quite easy to do. For each entity, the casing of the defining occurrence is stored. When a reference to this entity is encountered (i.e. a name that modulo casing is equal to the defining occurrence), then the casing is checked against that of the defining occurrence, and a warning is issued if it is different.
The current implementation seems to be something like: if a name is encountered in a defining occurrence, its casing is remembered; and any other name, regardless of scope or entity it refers to, is checked against that global table to have the same casing.
Waldek, is this what you mean?
Tom