home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / v20 / followdir / overview.d < prev    next >
Internet Message Format  |  1990-08-02  |  4KB

  1. From jsq@tic.com  Wed Jul  4 00:20:46 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA03827; Wed, 4 Jul 90 00:20:46 -0400
  4. Posted-Date: 3 Jul 90 20:41:28 GMT
  5. Received: by cs.utexas.edu (5.64/1.68)
  6.     id AA21914; Tue, 3 Jul 90 23:20:42 -0500
  7. Received: by longway.tic.com (4.22/tic.1.2)
  8.     id AA24803; Tue, 3 Jul 90 23:03:26 cdt
  9. From: Kee Hinckley <nazgul@alphalpha.com>
  10. Newsgroups: comp.std.unix
  11. Subject: Re: Standards Update, Recent Standards Activities [NLS stuff]
  12. Message-Id: <775@longway.TIC.COM>
  13. References: <387@usenix.ORG>
  14. Sender: std-unix@tic.com
  15. Reply-To: std-unix@uunet.uu.net
  16. Organization: asi
  17. Date: 3 Jul 90 20:41:28 GMT
  18. Apparently-To: std-unix-archive@uunet.uu.net
  19.  
  20. From:  nazgul@alphalpha.com (Kee Hinckley)
  21.  
  22. In article <387@usenix.ORG> From: <jsh@usenix.org>
  23. >To help you think about the problem, here's the way you'll have to
  24. >write the "hello, world" koan using the X/OPEN interfaces:
  25. ....
  26. >          (void)setlocale(LC_ALL, "");
  27. >          catd = catopen("hello", 0); /* error checking omitted for brevity */
  28. >          printf(catgets(catd, 1, 1,"hello, world\n"));
  29. ....
  30. >and using the alternative, proposed UniForum interfaces:
  31. ....
  32. >          (void)setlocale(LC_ALL, "");
  33. >          (void)textdomain("hello");
  34. >          printf(gettext("hello, world\n"));
  35. ....
  36. >I suppose if I had my druthers, I'd like to see a standard interface
  37. >that goes even farther than the UniForum proposal: one that adds a
  38. ....
  39. >          (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
  40. >          printf("hello, world\n");
  41. ....
  42. >but that would still be untested innovation.
  43.  
  44. First of all, I don't think that either of these add enough of value to the
  45. X/Open standard to make it worthwhile for those of using it to switch.
  46. The use of strings as an index into the catalog though is definitely a BAD IDA.
  47.  
  48. Why?  A number of reasons.  First of all it's ethnocentric.  You've just told
  49. every Easterner/MiddleEasterner that the default language is English.  Secondly
  50. it's inefficent to and a pain to implement.  Thirdly it can produce results
  51. which are just plain wrong.  I have different places in my application where
  52. the English string is currently the same.  Using these schemes it would always
  53. look up the same item in the catalog.  However in a different language the
  54. string might well be different, but there would be no way of changing it one place
  55. and not the other.
  56.  
  57. BTW.  Where can I get a specification of the Uniforum proposal (and comment
  58. on it)?
  59.  
  60. The complexity of the X/Open stuff is easily hidden on a per application basis.
  61. Anytime I want to reference a string in my application all I have to say
  62. is MC(foo), where foo is #defined appropriately.
  63.  
  64. Where I *do* see room for improvement is in the definition of the catalog
  65. file itself.  There is currently no specification for generating include
  66. files or anything else, and hand numbering the strings is a royal pain.
  67.  
  68. If you consider the X/Open form:
  69.  
  70. $set 1 OmUA
  71. $ #To
  72. 1 To:
  73. $ #From
  74. 2 From:
  75. $ #Subject
  76. 3 Subject:
  77.  
  78. (where '$ ' is a comment).  I've written a parser that
  79. treats comments beginning with '#' as special and allows
  80. '#' instead of the number.  Thus
  81.  
  82. $set 1 OmUA
  83. $ #To
  84. # To:
  85. $ #From
  86. # From:
  87. $ #Subject
  88. # Subject:
  89.  
  90. generates
  91.  
  92. #ifndef __msgsH
  93. #define __msgsH
  94.  
  95. #define SETOmUA    1
  96. #define OmUATo    1
  97. #define OmUAFrom    2
  98. #define OmUASubject    3
  99.  
  100. #endif
  101.  
  102. It would be nice to be able to rely on this kind of functionality.
  103.  
  104. -- 
  105. Alphalpha Software, Inc.    |    motif-request@alphalpha.com
  106. nazgul@alphalpha.com        |-----------------------------------
  107. 617/646-7703 (voice/fax)    |    Proline BBS: 617/641-3722
  108.  
  109. I'm not sure which upsets me more; that people are so unwilling to accept
  110. responsibility for their own actions, or that they are so eager to regulate
  111. everyone else's.
  112.  
  113. Volume-Number: Volume 20, Number 90
  114.  
  115.