Re: On NSIncrementalStore UUID Uniqueness
Re: On NSIncrementalStore UUID Uniqueness
- Subject: Re: On NSIncrementalStore UUID Uniqueness
- From: Charles Srstka <email@hidden>
- Date: Thu, 19 Jan 2017 17:20:32 -0600
> On Jan 16, 2017, at 12:48 PM, Quincey Morris <email@hidden> wrote:
>
> On Jan 16, 2017, at 09:08 , Charles Srstka <email@hidden <mailto:email@hidden>> wrote:
>>
>> The thing with file reference URLs degrading to file path URLs is in the Swift is actually not a bug, it’s deliberate (https://bugs.swift.org/browse/SR-2728 <https://bugs.swift.org/browse/SR-2728>). The Swift team decided that file reference URLs are not appropriate for the Swift URL value type.
>
> Does the given justification make any sense to you? It certainly makes no sense to me. Perhaps I’m missing something, but the discussion seems to me to conflate the idea of a reference type in Swift with the concept of “referencing” in the world in general:
>
>> “The[y] are both technically a different type in spirit[**] and they actually behave much more like a reference type than a structure.”
>
>
> By analogy, this is like saying that the Swift String type is good for representing people’s names, but that Obj-C NSString should be used for representing [US] people’s social security numbers, because a SSN is more like a reference than a value.
>
> In fact, URLs *are* strings — URLs as defined by the RFC, I mean — and that takes the semantics of relating the string to the resource that the string locates outside the scope of the representation itself.
>
> Perhaps the problem is that file reference URLs don’t have an eternal, unique string representation — that storing and reconstituting a file reference URL may produce a different string? In that case, it’s the URL (the value, not the type) that’s broken, and it’s just as broken in Obj-C as Swift.
>
>
> ** Incidentally, they aren’t a different *type* in spirit. File URLs and file reference URLs are both URLs: uniform [syntactically conformant with the RFC] resource [file, in this case] locators [specifiers of where to find]. The difference is in the semantics of the file system, which really has nothing to do with the syntax of the URL.
This post from Apple clarified their reasoning a bit:
https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20161205/001052.html <https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20161205/001052.html>
Basically, they wanted to get rid of the optionality on many of URL’s properties; in Swift 2, .path was optional, .lastPathComponent was optional, and possibly some others as well. Apparently the only times those methods ever returned nil was when the URL in question was a file reference URL; in Swift 3, those methods are no longer optional, but file reference URLs are no longer supported. :-/
The part of the message that I find ominous is where he says “If references were still important”. When you start hearing language like that from Apple, it’s usually a sign that they consider the feature no longer relevant and soon to be axed. File references were always a key differentiator in the Mac user experience, and it would be very sad to see them go.
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden