Re: patch to gnustep-base (Unicode and others)

[Serg Stoyan]

Hello, Richard Frith-Macdonald.

 RFM> >  RFM> Perhaps you can explain more ... as far as I cn see the above is 
 RFM> >  RFM> simply wrong.  Certainly initWithCString* methods are not 
 RFM> >  RFM> supposed to convert to unicode (as a general rule), and 
 RFM> >  RFM> OpenStep doesn't say they should - so I'm guessing you have 
 RFM> >  RFM> some meaning in mind that is not immediately obvious to me.
 RFM> >
 RFM> >   Here is the citation from "OpenStep Specification" (c) 1994 NeXT 
 RFM> >   Computer Inc. Class NSString, page 2-127:
 RFM> >   "- (id)initWithCString:(const char *)byteString
 RFM> >
 RFM> >   Initializes the receiver, a newly allocated NSString, by converting 
 RFM> >   the one-byte characters in byteString into Unicode characters. 
 RFM> >   byteString must be a null-terminated C string in the default C 
 RFM> >   string encoding."
 RFM> 
 RFM> OK ... guess I was wrong about that ... it *does* seem to say strings 
 RFM> should be converted to unicode ... but that's incorrect/misleading 
 RFM> documentation.

  What documentation do you reccomend me to use? Apple's FoundationKit 
  and AppKit frameworks documentation? It says the same. What else?
  Maybe i misunderstand you at some point?
 
 RFM> If you look in the class description documentation, it tells you that -
 RFM> 
 RFM> 'While the actual representation of character strings stored in NSString 
 RFM> and NSMutableString is independant of any particular implementation, 
 RFM> you can in general think of the contents of NSString and NSMNutableString
 RFM> object as being, canonically, Unicode characters (defined by the unichar 
 RFM> data type)'
 RFM> 
 RFM> Really, this means that you should not take the method descriptions too 
 RFM> literally, they are describing an API, not particular internal 
 RFM> implementation details.

  You're right, but... I guess methods of the class have to interpret
  its contents in the same way. For example, if dataUsingEncoding try to
  convert *from* Unicode, initWithCString have to convert *into* Unicode. 
  You may replace "Unicode" with "Binary", no difference. I guess
  Unicode is just portable way to store strings...
 
 RFM> >  RFM> > - adds 2 languages into Resources/Languages: Russian and 
 RFM> >  RFM> >   Ukrainian;
 RFM> >  RFM>
 RFM> >  RFM> Thanks, but I can't use them ... as I don't know what encoding 
 RFM> >  RFM> you have created them in.  I have added a README file to the 
 RFM> >  RFM> Resources/Languages subdirectory to say what format language 
 RFM> >  RFM> files *should* be in (and corrected some errors in the existing 
 RFM> >  RFM> files).
 RFM> >
 RFM> >   It's ok. I've just updated from CVS and created this files by 
 RFM> >   cvtenc'ing them, just like README says. But... When i start any app 
 RFM> >   i get this message:
 RFM> >
 RFM> >   File NSDictionary.m: 458. In [GSDictionary -initWithContentsOfFile:] 
 RFM> > Contents of file 
 RFM> > '/home/stoyan/GNUstep/System/Libraries/Resources/Languages/Russian' 
 RFM> > does not contain a dictionary
 RFM> 
 RFM> All I can suggest here is making sure you have the latest code installed.
 RFM> I fixed a bug in loading 16-bit unicode property lists a day or two ago.

  I have the latest CVS version. I start every day by 'cvs -z3 update' ;)
 
 RFM> >   Here is my some environment vars:
 RFM> >   [stoyan@localhost]$ echo $GNUSTEP_STRING_ENCODING; echo $LANG
 RFM> >   NSKOI8RStringEncoding
 RFM> >   ru_RU.KOI8-R
 RFM> >   I've attached Russian and UkraineRussian(conforming to Locale.aliases)
 RFM> >   files as well.
 RFM> 
 RFM> Thanks, I've added them (I converted to ascii with \u escapes for 
 RFM> consistency with the other files, but that should make no difference).

  By the way, you probably forgot to upload these files to CVS.

  [some skipped...]
 
 RFM> Property lists should be ascii ... so I prefer to keep an ascii property 
 RFM> list containing \u escape sequences for non-ascii character, and create 
 RFM> the other files temporarily (for editing) using cvtenc
 RFM> 
 RFM> >   In this case we use Unicode file, and proplist files remains for 
 RFM> > editors.
 RFM> 
 RFM> But keeping multiple copies in different formats could let them get out 
 RFM> of sync with each other if you are not careful.

  [some skipped...]
 
 RFM> while unicode files are also portable, I'd still prefer to stick to 
 RFM> ascii files with \u escape sequences.  That is, if we are sticking to 
 RFM> one portable format for consistency, I'd prefer it to be the ascii.
 
  Completely agree at this point.

 RFM> > PS: Another thing i've mentioned (and i guess should be somwhere in
 RFM> > Documentation) is about using non-ascii characters when initializing 
 RFM> > NSString variable. I mean using such definition:
 RFM> >
 RFM> > NSString  *some_string = @"some non-ascii characters";
 RFM> >
 RFM> > is deprecated. In this case string doesn't not converted into Unicode 
 RFM> > and results is unpredictable, or something.
 RFM> 
 RFM> Well, OpenStep spec simply tells you not to do it (I'd say that's closer 
 RFM> to 'illegal' than 'deprecated') in the NSString class description.

  You are right.
 
 RFM> Where do you think this should be documented in GNUstep ?

  Sorry, my mistake. No need to document it according to above you say. 
  
-- 
Serg Stoyan