-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")
Side Note: I would also REALLY like to see a swift native improvement on
NSAttributedString with native literal support.
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
