Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]

[Helge Hess]

On 8. Mai 2005, at 04:00 Uhr, Sheldon Gill wrote:
> > > P.S.: All the methods handling C strings are in the depreceated   
> > > section now.

How disappointing! :-|

I suppose it was dropped because people did not understand what it is  
doing / good for and misused the methods (pretty similiar to - 
fileSystemRepresentationWithPath: which is seldom used).

> > That is not quite true, actually many of them are replaced by  
> > methods  taking an encoding parameter in addition. E.g. cString  
> > becomes  cStringUsingEncoding: and so on.

Thats not the same. The -initWithCString: per definition takes  
strings in the system encoding, so if you are getting a value from a  
standard C-API (say readlink()) you now need to do:

  s = [NSString stringWithCString:buf
                encoding:[NSString defaultCStringEncoding]];

which obviously is a major inconvenience (and slowdown!) when  
interfacing with C.

> That is right. As I see it, they are rightly trying to move things  
> forward for better internationalisation.

I wonder how this is supposed to improve internationalization. A  
pretty good optimization which had _no_ drawback wrt  
internationalization was dropped in favor to a method which will  
hardly get used in practice.

Instead they could have used their energy to add Cocoa API for  
supporting arbitary encodings without resorting to CoreFoundation.  
_That_ would have been an improvement for internationalization.

> Relying on a "default" encoding and using a C string isn't a good  
> idea.

Why not? This way its guaranteed to match. The "default" encoding is  
the encoding configured in your Unix environment. You know, modern  
Unix _has_ proper support for localization (see LANG, LC_xxx etc)?

> In the modern unix world you are much better off using UTF8 strings.
> In the modern windows world it should all be UTF16

Hm, yes? This is why UTF-8 or UTF-16 might be the default C-String  
encoding if this is the case. This is what -initWithCString: aka  
defaultCStringEncoding is made for! If your Unix does UTF-8, you just  
switch the default encoding and everything works instantly.

Also your point doesn't apply since we already have - 
initWithUTF8String: (every C API which doesn't use the system  
encoding most likely uses UTF-8 on Unix) and -initWithCharacters:.
So dropping -initWithCString: gains you nothing here.


Oh well,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org