> On May 7, 2016, at 11:37 AM, Patrick Smith via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I think everyone possibly has different definitions of what ‘Swift-native
> rethinking’ could involve? My thoughts are, the Swift standard library is a
> base library of types and algorithms. There’s then a sister library that has
> serialisation, file reading and writing, and HTTP networking, dates, and
> more. At the moment that library is Foundation.
>
> I think a good rule for Swift 3 has been, if some feature wasn’t already in,
> would it be added now if freshly proposed? Is it too far to ask what would a
> fresh take on Foundation look like?
>
> There are certain things with Foundation that make it feel outdated or
> possibly less Swift-like:
> - File references/paths are currently a part of NSURL. While this is 10 times
> better than the old NSString API, isn’t it still a bit odd, and a bit
> unfortunate to be bringing forward to Linux? There are a whole set of APIs of
> NSURL that only apply to files, and other another set that only apply to
> actual RFC 2396 URLs. Plus you have the NSFileManager APIs and the
> NSURLSession APIs, one for files and one for web URLs, and they both use the
> same type.
> - Why does the library Alamofire have 16,000 stars given that it uses the
> relatively new API NSURLSession? Would a Swift Foundation aim to get a
> similar API?
> - NSTask I think is a reasonable Objective-C API, but nowadays is verbose and
> throws exceptions: https://www.shinobicontrols.com/blog/scripting-in-swift
> <https://www.shinobicontrols.com/blog/scripting-in-swift>
> - NSUserDefaults is designed to write to file storage by a single client as
> far as I know. i.e. would it be appropriate for a web server?
For what it’s worth, this isn’t true. NSUserDefaults supports concurrent access
from arbitrary numbers of clients.
David
> - Foundation is originally designed in a time before closures and before GCD.
> It’s had some additions to work those features in, but they don’t feel like
> Foundation has been based upon them.
> - Having two types, the [NS]OutputStream class, and the OutputStreamable
> protocol, but they seemingly have nothing to do with each other? Why the
> designs of one or both change so that NSOutputStream could conform to
> OutputStreamable?
> - APIs such as NSOperation that rely on key value coding and observation.
> - NSOperationQueue, which back in its day added a nice Objective-C API over
> dispatch queues, but today could probably be achieved by use of protocol
> extensions and a smaller class that complement GCD?
> - NSSortDescriptor, designed using key value coding.
>
> Matthew Johnson raised the possibility of a “split between those who favor
> various libraries”. I take your point that “We are trying to avoid exactly
> the split you are concerned about.”
>
> I think it is worth listing what Swift-native thinking includes. Here are my
> ideas based on what I’ve seen from the standard library and the community:
> - Modular protocol oriented design
> - Small focused APIs
> - Elegant use of closures
> - Explicit rejection of old conventions in order to find the best possible API
> - Value types of course, which we have coming thanks to the effort here
> - Ability to design with ‘micro’ value types, where objects would have been
> cumbersome or inefficient in Objective-C.
>
> I have a feeling that for developers who start by learn Swift conventions and
> who know have exposure to other libraries and frameworks, that Foundation
> will feel a bit foreign to them. I feel there will be a split between library
> choices, as people go for something with more focused APIs that take
> advantage of Swift more. Is the plan for Foundation to still be a core part
> of Swift in the next 5+ years?
>
> Foundation is a great API for the tools they had available with Objective-C
> and thoughtful naming and design. I feel if someone were to design an API
> given the current tools we have now, it would be very different.
>
> I think modernising Foundation for Swift is a worthy effort, but seemingly
> making it the defacto sister library to the standard library feels a bit odd.
>
>
>> On 8 May 2016, at 2:53 AM, Tony Parker via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>> On May 7, 2016, at 6:06 AM, Jonathan Hull <jh...@gbis.com
>>> <mailto:jh...@gbis.com>> wrote:
>>>
>>> -1 on this as well. How much does dropping NS really help things anyway?
>>>
>>> All it does is force everyone to learn which things still have NS and which
>>> don’t. It also makes things much more difficult to search for… searching
>>> for NS_ gives the results you want quickly vs searching for anything in
>>> Swift foundation (e.g. Array -- which gives you a mixture of other
>>> programming languages and Taylor Swift gossip).
>>>
>>> My proposal would be to keep NS for everything and then slowing making
>>> versions without the prefix, either by rewriting them to be better in Swift
>>> or simply aliasing the NS version. Once you have critical mass for useful
>>> things (around Swift 5~6), you can separate all the NSStuff out into their
>>> own NSFoundation which would be used only for backwards compatibility.
>>>
>>> To the inevitable question: Wont having NS and Non-NS versions be confusing
>>> (especially if some are just aliases)? My answer is that it is less
>>> confusing than this proposal. There is a simple rule: Things without NS are
>>> always the new and preferred methods. Things with NS are there for
>>> compatibility and will continue to work the way they do in ObjectiveC (even
>>> if you have to import “NSFoundation” to get them instead of just
>>> “Foundation")
>>>
>>
>> I think that this approach ends up with confusion as well. Maybe we end up
>> with UserDefaults and NSUserDefaults? One is written in Swift and other is
>> not, but what difference would that make to the caller? Swift itself is not
>> written completely in Swift. Instead, let’s have one UserDefaults that has
>> an API appropriate for Swift. You’ve seen some of that already with changes
>> to the names of its methods
>> (https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575
>>
>> <https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575>
>> as one example, which takes advantage of overloading to simplify the API).
>>
>>> Side Note: I would also REALLY like to see a swift native improvement on
>>> NSAttributedString with native literal support.
>>
>> NSAttributedString was part of the value types proposal at the beginning but
>> deferred for a few practical reasons. One reason is that I want additional
>> existential support in the language first. AttributedString has the concept
>> of a “longest effective run”, which is calculated by checking for equality
>> between attributes. Attributed string should allow for
>> AnyEquatableAndCopyable members of its attribute dictionary. A second
>> problem is that the entire Cocoa text system (and hundreds of higher level
>> APIs) are based on top of the NSString Index concept, which is hidden behind
>> the unicodeScalar view of Swift.String. I would like a more unified story of
>> how these two can interoperate before we revamp the base type.
>>
>> Both of these are solvable, but they require time to collaborate between
>> teams to decide what the right platform-wide approach is. We’ll do it, but
>> it will not happen immediately.
>>
>>>
>>>> There’s no question that we can improve Coding for Swift. I have actually
>>>> explored this area quite a bit although I don’t have anything planned for
>>>> Swift 3 at this time.
>>>>
>>>> The general point is though, that we can do it by extending Foundation in
>>>> that direction over time. In fact, keyed archiving is the perfect example
>>>> of how we were able to do just that in the past in Objective-C. NSArchiver
>>>> already existed and served a particular purpose, so we extended the
>>>> concept into NSKeyedArchiver using the facilities available to us at the
>>>> time.
>>> I would be curious to hear about your explorations (either in another
>>> thread or offlist)
>>>
>>> I have written a couple of experimental versions of an improved Coding
>>> system for Swift. The key idea is to use closures to allow coding of
>>> arbitrarily complex nested types (e.g an array of tuples of Dictionaries:
>>> [(String, [String:Int])] ). It works pretty well, but unfortunately
>>> currently taxes the compiler to the point where it randomly crashes during
>>> compilation. I am waiting for the new generics stuff to come online before
>>> I explore further, since I believe that will dramatically simplify the code.
>>>
>>> The other idea which I would like to see replicated is that it codes to an
>>> intermediate format which can then be transformed to/from binary data, XML,
>>> BSON (JSON + some representation for Binary Data) or some other format...
>>>
>>> It also interoperates very well with existing NSCoding classes, which is an
>>> important feature.
>>>
>>> Thanks,
>>> Jon
>>
>> One thing to think about here is what the role of NSCoding is in the first
>> place. It was designed to support archiving of UI objects to nib files. It
>> has been pressed into service for all kinds of other interesting tasks
>> since; UI state restoration, document formats, and IPC wire protocol, to
>> name a few. It may be worthwhile to decide if these are really all the same
>> use case or not. I’m honestly not sure yet. Some of these are very focused
>> on dynamic behavior (that is, the object graph is not known in advance). For
>> some, custom object types are really important (NSXPC takes full advantage
>> of this, and is basically its reason for existence over the raw libxpc API).
>> For others it is not (a raw document file of one million double values).
>> Some of these have different performance requirements than others (archiving
>> fast is important to IPC but unarchiving fast is important to loading nib
>> files).
>>
>> - Tony
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
