Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS NSURL vs NSString: discussion?

M

MrFusion

macrumors 6502a
Original poster
Jun 8, 2005
613
0
West-Europe
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?
 
K

kainjow

Moderator emeritus
Jun 15, 2000
7,958
7
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

Catfish_Man

macrumors 68030
Sep 13, 2001
2,579
2
Portland, OR
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

Cinder6

macrumors 6502a
Jul 9, 2009
509
50
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 :)
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom