So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
"varying capitalisation" would be my choice "varying letter-cases" may be clearer, and it avoids the ambiguity on "cases" that started the discussion
Keep it short. Maybe "varying id letter case: <oldid> <thisid>"?
Perhaps "mismatched <oldid> <thisid>"?
It has to be CLEAR which means things like 'caps' won't do because it is not obvious that this is an abbreviation.
How about straightforward English:
The capitalization of the definition <original> does not match <current>.
or more tightly:
Capitalization of definition <original> does not match <current>.
This way there would be no question as to what the message means. I think that a few extra bytes for clarity is worthwhile.
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:
So, what's best now, "varying capitalisation", "varying capitals", "mismatched caps"?
"varying capitalisation" would be my choice "varying letter-cases" may be clearer, and it avoids the ambiguity on "cases" that started the discussion
Keep it short. Maybe "varying id letter case: <oldid> <thisid>"?
Perhaps "mismatched <oldid> <thisid>"?
It has to be CLEAR which means things like 'caps' won't do because it is not obvious that this is an abbreviation.
How about straightforward English:
The capitalization of the definition <original> does not match <current>.
or more tightly:
Capitalization of definition <original> does not match <current>.
"Definition" is generally not correct, since it can also be an applied occurrence of an identifier.
This way there would be no question as to what the message means. I think that a few extra bytes for clarity is worthwhile.
I'd prefer to have it in two lines, so the file names/line numbers can refer to both points of usage. But breaking a sentence in such a way, with a (generally) different line number in between, might be confusing. So I'd then suggest something like:
foo.pas:42: capitalization of identifier <current> does not match previous one foo.pas:17: previous capitalization <original>
or
foo.pas:42: msimatched capitalization of identifier <current> foo.pas:17: previous capitalization <original>
Adriaan van Os wrote:
The compiler will have to look at the date first and, if that happens to be April 1, issue the message "I don't like your cap".
LOL. :-)
Frank
In article 200302171417.PAA25667@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
I'd prefer to have it in two lines, so the file names/line numbers can refer to both points of usage. But breaking a sentence in such a way, with a (generally) different line number in between, might be confusing. So I'd then suggest something like:
foo.pas:42: msimatched capitalization of identifier <current> foo.pas:17: previous capitalization <original>
This sounds perfect to me.
Martin Liddle wrote:
In article 200302171417.PAA25667@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
I'd prefer to have it in two lines, so the file names/line numbers can refer to both points of usage. But breaking a sentence in such a way, with a (generally) different line number in between, might be confusing. So I'd then suggest something like:
foo.pas:42: msimatched capitalization of identifier <current> foo.pas:17: previous capitalization <original>
This sounds perfect to me.
Doesn't it break some of the error parsing IDE's ?
I am writing a Pascal interface to an existing library (CarbonLib) that has underscores in some (only a few) of its symbol names. GPC issues a warning: identifiers should not start with an underscore. Before deciding to ignore the message or to change the name -- is there a special reason why identifiers should not start with underscores, except good use and general convention ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
I am writing a Pascal interface to an existing library (CarbonLib) that has underscores in some (only a few) of its symbol names. GPC issues a warning: identifiers should not start with an underscore. Before deciding to ignore the message or to change the name -- is there a special reason why identifiers should not start with underscores, except good use and general convention ?
Because the standard says so. (`-Wno-underscore' if you don't like that.)
Frank
I got an warning message about underscores at the *end* of an identifier...! Does the standard ban that too???
(I know this is more than a "little" unusual, but I had specific reason for this: easy "quick'n'dirty" search'n'replace, etc., for porting purposes.)
Grant
At 7:08 PM +0100 18/2/03, Frank Heckenbach wrote:
Adriaan van Os wrote:
I am writing a Pascal interface to an existing library (CarbonLib) that has underscores in some (only a few) of its symbol names. GPC issues a warning: identifiers should not start with an underscore. Before deciding to ignore the message or to change the name -- is there a special reason why identifiers should not start with underscores, except good use and general convention ?
Because the standard says so. (`-Wno-underscore' if you don't like that.)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
Grant Jacobs wrote:
I got an warning message about underscores at the *end* of an identifier...! Does the standard ban that too???
Yes.
: 6.1.3 Identifiers : : Identifiers can be of any length. The spelling of an identifier shall be : composed from all its constituent characters taken in textual order, without : regard for the case of letters. No identifier shall have the same spelling : as any wordÂsymbol. Identifiers that are specified to be required shall have : special significance (see 6.2.2.10 and 6.12). : : identifier = letter { [ underscore ] ( letter | digit ) } . : : underscore = `_' . : : NOTE --- An identifier cannot begin or end with an underscore, nor can two : underscores be adjacent.
Frank
On Mon, Feb 24, 2003 at 01:29:33PM +1300, Grant Jacobs wrote:
I got an warning message about underscores at the *end* of an identifier...! Does the standard ban that too???
Yes. Underscores can't occur at either beginning or end of an identifier, and two underscores can't be adjacent.
ISO 10206, 6.1.3:
identifier = letter { [ underscore ] ( letter | digit ) } .
Emil Jerabek
(I know this is more than a "little" unusual, but I had specific reason for this: easy "quick'n'dirty" search'n'replace, etc., for porting purposes.)
Grant
At 7:08 PM +0100 18/2/03, Frank Heckenbach wrote:
Adriaan van Os wrote:
I am writing a Pascal interface to an existing library (CarbonLib) that has underscores in some (only a few) of its symbol names. GPC issues a warning: identifiers should not start with an underscore. Before deciding to ignore the message or to change the name -- is there a special reason why identifiers should not start with underscores, except good use and general convention ?
Because the standard says so. (`-Wno-underscore' if you don't like that.)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
--
Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com
The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.
-
Adriaan van Os -
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Grant Jacobs -
Martin Liddle -
Tom Schneider