Why not use path-based API? (was: Loading image resources)
No one should be using path-based API any more, generally. You should use URL-based equivalents. Why? Really, why? Certainly there are APIs where we have to use URL's and we have to convert the path into a URL, but where a non-deprecated path-based URL exists, what current or future obstacles do you foresee? The URL doesn't seem to be more predicable or persistent, for example. Thanks for any insight. I've been really happy to see the last of the old-style colon-separated names and move to something I can understand, a pathname. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why not use path-based API? (was: Loading image resources)
On Sep 14, 2014, at 00:57 , Aandi Inston aa...@quite.com wrote: Why? Really, why? Certainly there are APIs where we have to use URL's and we have to convert the path into a URL, but where a non-deprecated path-based URL exists, what current or future obstacles do you foresee? The URL doesn't seem to be more predicable or persistent, for example. It’s not an absolute rule, and it’s certainly possible to defend the use of path APIs, but here are some of my reasons: 1. NSURL-based APIs were introduced *in order to* replace path-based APIs, so using the new APIs maybe helps to future-proof your code. IOW, sometimes Apple gives us hints as to what continents are moving in the API geoscape, and sometimes they do this by replacing APIs with new ones that more or less seem to do the same thing — until later they don’t. For example, although Cocoa generally requires *file* URLs for non-internet things, it’s possible that in the future we’ll need to locate resources that don’t have a traditional path. 2. I think some path-based APIs had quirks, for example about handling paths that started with a tilde, or other environment-related issues. Generally, NSURL-based APIs are regular in their behavior. However, I don’t have any examples of this difference at hand, and I could easily be wrong about this point. 3. Some NSURL-based APIs improved or corrected the methods that they replaced. For example, the new APIs follow standard conventions for returning errors. 4. Some things can only be done with NSURL-based APIs. For example, sandboxed access to files chosen by users. Because of #3 and #4, you’re going to be using NSURL at least some of the time, and mixing the two API styles gets messy fast. If you have to pick one, NSURL is the one to pick. Here are some of the reasons for using path-based APIs: 1. You’re writing a command line utility that’s (e.g.) POSIX-compliant or crosses to other UNIX platforms. In that case, its probably more consistent to stick with paths, unless you have some other reason to deal with URLs. 2. You’ve got existing code that uses path-based APIs, and you can’t justify the time it would take to convert. Because the above is too long to be useful in response to posts on other issues, I decided to reduce it to “You should use URL-based equivalents generally.” ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why not use path-based API? (was: Loading image resources)
Le 14 sept. 2014 à 10:23, Quincey Morris quinceymor...@rivergatesoftware.com a écrit : On Sep 14, 2014, at 00:57 , Aandi Inston aa...@quite.com wrote: Why? Really, why? Certainly there are APIs where we have to use URL's and we have to convert the path into a URL, but where a non-deprecated path-based URL exists, what current or future obstacles do you foresee? The URL doesn't seem to be more predicable or persistent, for example. It’s not an absolute rule, and it’s certainly possible to defend the use of path APIs, but here are some of my reasons: 1. NSURL-based APIs were introduced *in order to* replace path-based APIs, so using the new APIs maybe helps to future-proof your code. IOW, sometimes Apple gives us hints as to what continents are moving in the API geoscape, and sometimes they do this by replacing APIs with new ones that more or less seem to do the same thing — until later they don’t. For example, although Cocoa generally requires *file* URLs for non-internet things, it’s possible that in the future we’ll need to locate resources that don’t have a traditional path. 2. I think some path-based APIs had quirks, for example about handling paths that started with a tilde, or other environment-related issues. Generally, NSURL-based APIs are regular in their behavior. However, I don’t have any examples of this difference at hand, and I could easily be wrong about this point. 3. Some NSURL-based APIs improved or corrected the methods that they replaced. For example, the new APIs follow standard conventions for returning errors. 4. Some things can only be done with NSURL-based APIs. For example, sandboxed access to files chosen by users. Because of #3 and #4, you’re going to be using NSURL at least some of the time, and mixing the two API styles gets messy fast. If you have to pick one, NSURL is the one to pick. Here are some of the reasons for using path-based APIs: 1. You’re writing a command line utility that’s (e.g.) POSIX-compliant or crosses to other UNIX platforms. In that case, its probably more consistent to stick with paths, unless you have some other reason to deal with URLs. 2. You’ve got existing code that uses path-based APIs, and you can’t justify the time it would take to convert. Because the above is too long to be useful in response to posts on other issues, I decided to reduce it to “You should use URL-based equivalents generally.” One other point is that NSURL API abstract the way you access a file and let you transparently use different concept to reference a file like 'file reference'. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why not use path-based API? (was: Loading image resources)
On Sep 14, 2014, at 2:57 AM, Aandi Inston aa...@quite.com wrote: No one should be using path-based API any more, generally. You should use URL-based equivalents. Why? Really, why? Certainly there are APIs where we have to use URL's and we have to convert the path into a URL, but where a non-deprecated path-based URL exists, what current or future obstacles do you foresee? The URL doesn't seem to be more predicable or persistent, for example. Thanks for any insight. I've been really happy to see the last of the old-style colon-separated names and move to something I can understand, a pathname. In addition to what others have said, NSURL can know it represents a file URL and therefore can do smart things like cache file metadata (called resource values in the API). A string can look like a path even when it isn't and it can not look like a path when it is, so NSString can't have any file-specific smarts built into it. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why not use path-based API? (was: Loading image resources)
Performance is another reason. IIRC, in earlier OS X releases it turned out that there was significant overhead stemming from converting between different types of file references as a call went up and down the stack — NSString/CFString —NSURL/CFURL — FSRef — C strings, etc. (This may sound trivial, but it's the kind of trivial thing that can eat up CPU time inside loops or performance-critical code.) So there's been some effort to standardize on NSURL/CFURL, at least above the POSIX/kernel layer. So I don't have numbers to back this up, but my understanding is that NSURL-based APIs will be slightly faster than NSString-based ones. Though probably not enough faster to worry about unless your code is performance-sensitive. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
