Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!cbnewsc!nevin1 From: nevin1@cbnewsc.ATT.COM (nevin.j.liber) Newsgroups: comp.lang.c++ Subject: Re: extern "language" Message-ID: <1115@cbnewsc.ATT.COM> Date: 2 Jun 89 23:28:36 GMT References: <2922@pegasus.ATT.COM> Reply-To: nevin1@ihlpb.ATT.COM (nevin.j.liber) Organization: AT&T Bell Laboratories Lines: 34 In article <2922@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: >In article <833@cbnewsc.ATT.COM> nevin1@ihlpb.ATT.COM (nevin.j.liber) writes: >>(IMHO) From a language point of view, it is more 'consistent' to have >>this case-sensitive... >Oh, be real. Serve the user -- in this case the programmer. Consistency >in support of the priest-class that can remember the convention is worthless. Using your own argument, to allow 'language' in extern "language" to be case-insensitive would become a convention concerning string literals which only the priest-class, of which, as you say, >Yes, I am fully ordained. :-), could remember, and therefore is useless. Inconsistency leads to a feeling of kludgyness about a language. Look at C: for at least the next ten years (assuming this doesn't get changed for the final ANS C standard, of course), initializer lists can have a comma after the last element while declarator lists cannot. It SHOULD (IMHO) be either both (which would be my choice if I were doing the designing) or neither; the way it is now, it seems 'wrong' and counter-intuitive. There are times when it is worth giving up consistency; however, this isn't one of them. In reality, what percentage of total code will contain the extern "language" construct? Very, very little. How many languages do you plan to incorporate in any given program? For most people, not more than one or two. To make string literals in this circumstance be case-insensitive would be far worse than having the user look up the spelling/casing of the language name once per project. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751