[swift-corelibs-dev] NSURL getResourceValue

Daniel Eggert danieleggert at me.com
Fri Apr 1 03:21:53 CDT 2016

> On 31 Mar 2016, at 21:44, Tony Parker <anthony.parker at apple.com> wrote:
> Hi Zach, Daniel,
>> On Mar 31, 2016, at 11:03 AM, Zach Waldowski via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>> The semantics of the methods are fairly nuanced in ObjC.
>> You can have a resource value that fails to be fetched, or one that
>> succeeded to fetch but had no value. A Swift version would model this as
>> `throws -> AnyObject?`.
>> For the dictionary version, you may ask for a resource value, it
>> succeeds, but isn't included in the dictionary because it was `nil`.
>> This version is modeled "fine" in Swift, but like you mentioned it also
>> isn't available.
>> Sorry for not being clear — the point was that it is desired for
>> corelibs-Foundation to have the same API as Darwin-Foundation, as has
>> been mentioned on this mailing list. Anything outside that has to be
>> approved (internally to Apple, I think?), and this just hasn't been
>> worked through yet.
>> Unrelated, it also appears that the underlying versions
>> (CFURLCopyResourcePropertyForKey and CFURLCopyResourcePropertiesForKeys)
>> aren't included in corelibs-CoreFoundation. I have to imagine those are
>> pretty platform-specific, but I can't comment on their conspicuous
>> disappearance because I have no more knowledge than you do. ;)
>> Zach
> Yes, the reason we left these out is that they are very platform specific.
> I could potentially see some kind of solution here where a dramatically reduced set of keys are available on all platforms. Things like file name and file size are probably able to be implemented in a cross-platform way. For now, I just left the whole thing out because sorting through what would be portable or not would be a pretty large task.
> - Tony

Thanks for the info. I agree that a Swift overlay for Darwin Foundation would be great, and adding those versions to SwiftFoundation would be most excellent. I remember that when these APIs were added to OS X once of the reasons was that it provides a unified API for all these kinds of things, and it allows the library to cache these, dramatically reducing the calls to stat(2) and friends.

I think the fact that these are so platform specific is a good reason to include them: Foundation’s goal is to “Provide a level of OS independence, to enhance portability”.


More information about the swift-corelibs-dev mailing list