macOS NSURL vs NSString: discussion?

[MrFusion]

I thought NSURL vs NSString would make a nice discussion for the experts here.

Cocoa seems, to me at least, undecided between NSURL and NSString. Many filesystem methods require a NSURL path, (e.g. in the NSDocument class). However, if you want to create a NSURL to a locale path, you have to use fileURL... methods, instead of URL... methods. Also, the NSURL class lacks easy ways to change the path. NSString has many methods for appending or deleting path components. NSString paths are also used many times for writing out data directly. When it comes down to use of use, NSString paths are the thing to do.

My code is littered with going back and forth between NSURL and NSString objects for paths. I don't like it, it is ugly.

It's probably easy to write a category for NSURL to mimic the NSString methods, but then why is such basic functionality not included in the class from the beginning?
Why is cocoa so seemingly confused between NSString and NSURL (or am I the one who is confused)?
And as for the future, will it stay like this or will one win over the other?

NSURL vs NSString: who is the winner?

 

[kainjow]

A lot of those methods that work on paths have a corresponding CF function that works on URLs (for example CFURLCreateCopyDeletingPathExtension() and stringByDeletingLastPathComponent), so either NSString internally is converting itself to a URL (which seems wasteful) or it just has its own implementations of these CF functions.

I'd use NSStrings for local paths as much as possible since an NSURL can also be used to reference an external file. If a class supports loading from an NSURL it's assumed that it handles loading external files (from a server) and if you don't want that then use an NSString.

 

[Catfish_Man]

NSURL is the winner, but I can't explain why yet. Sorry.

<edit> For those with access to WWDC08 sessions, check out #375 </edit>

 

[MrFusion]

NSURL is the winner, but I can't explain why yet. Sorry.

<edit> For those with access to WWDC08 sessions, check out #375 </edit>

It's august. Can you explain now? Or not until Snowy is out hunting?

 

[Catfish_Man]

Not until SnowLeopard is out.

 

[kainjow]

NSURL is the winner, but I can't explain why yet. Sorry.

<edit> For those with access to WWDC08 sessions, check out #375 </edit>

I just skimmed through it. Pretty interesting. Guess I was wrong

 

[MrFusion]

Not until SnowLeopard is out.

Ok. Do you promise to tell when Snowy is on the loose?

 

[Cinder6]

I'm surprised to find myself so intrigued by a discussion of NSURL.

 

[Catfish_Man]

Ok. Do you promise to tell when Snowy is on the loose?

Yup. Please bump this if I forget.

 

[Cinder6]

So, can you talk about it?

 

[Catfish_Man]

NSURL's API and role has been expanded significantly in Snow Leopard. Some key points:

* File reference URLs and bookmarks: There's a new form of URL called a file reference URL, which is the replacement for the old Carbon alias and FSRef types. It will track files even if they move, and can be serialized to and from "bookmarks", which are the persistent on-disk representation of this.

* File properties: Replacements for the old FSGetCatalogInfo and similar functions have been added through a unified file property API.

* Speed: Various caches have been added to NSURL, and more of the other Cocoa APIs have standardized on it. This avoids redundant stat()s and open()s, and the conversion costs to/from paths, FSRefs, etc...

 

[Cinder6]

Pretty cool. When I saw that the documentation pages all changed to the (horrible) ones they use for the iPhone reference, I checked out the revisions for NSURL. Saw bookmarks, but didn't bother finding out what it meant

 

[kainjow]

There are still some classes that don't support URLs yet. Tad annoying.