Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]

[Sheldon Gill]

Helge Hess wrote:
> How disappointing! :-|

Yes, it is rather.

> 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).

I'm sure that has a lot to do with it. There isn't anything in the 
on-line documentation so far which would point to reasons.

It could also be a prelude for newer APIs which rely on UTF16.

> > > 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.

Yes, except on MacOS-X you'd go

s = [NSString stringWithUTF8String: buf];

which is an easy update from

s = [NSString stringWithCString: buf];

so for it isn't a significant inconvenience. As for slowdown, I'm not 
sure that Cocoa doesn't now call down to specify the encoding anyway.

I'd also say that a Cocoa application should never call readlink() 
anyway. It's supposed to resolveSymLinksInPath ;)

> > 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.

See above. I think you're right and encoding: will not be used very 
much. I'm sure this is what Apple wants.

> 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.

Absolutely. It seems a very simple thing to do as well.

Actually, a lot of the revisions are IMO half-way. Where there is a 
reasonable CF way they often point and that instead. Worse-is-better

> > 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)?

I know. I can similarly argue that the "default" encoding is always UTF8 
so just go with that.

The real problem I see with relying on the "default" encoding is when 
moving from machine to machine.

> > 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.

You're forgetting. This is Cocoa and there is no your Unix and mine. 
There is only MacOS-X.

> 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.

I do get your point. I think the rationale has more to do with 
social/human factors and technical merits.

> Oh well,

Exactly. I'm trying to defend Apples decision so much as interpret it.
I've come to the opinion that it isn't entirely without merit.


Regards,
Sheldon