Should deprecated / unsafe classes be renamed with some sort of prefix, such as UnsafeCoder? Or leave them as original, NSCoder? Just to highlight alternatives should be used instead.
> On 7 May 2016, at 8:06 AM, Tony Parker via swift-evolution > <[email protected]> wrote: > > Hi David, > >> On May 6, 2016, at 2:56 PM, David Waite <[email protected] >> <mailto:[email protected]>> wrote: >> >> -1 On the group as-is. I do not believe all of these classes have the >> behavior that would be expected if ‘foundation’ were a from-scratch >> foundational library for Swift (as it exists on non Apple platforms). This >> will lock Swift into an evolutionary path for these types going forward. >> >> There is enough here that I will just pick one example to focus on - >> NSCoding/NSCoder, and elements I would suspect from such a from-scratch >> design >> >> - Coding would incorporate SecureCoding into its design (I did not see >> NSSecureCoding even on the list of protocols to get the prefix dropped) > > SecureCoding should be on the list actually. > >> - Archiver/Unarchiver would not exist; we would only have keyed versions >> - Coder would be a split in half to Coder and Decoder >> - Coder and Decoder would be protocols >> - The Coder protocol might have a single method, encode(value:Coding, >> forKey:String) >> - The Decoder protocol might single method, <T:Coding> decode(type:T.Type, >> forKey: String) -> T? >> - Compiler generation of a default Coding implementation >> >> And possibly more such as: >> - Add Coders limited to trees of objects vs graphs, to allow the >> Coder/Decoder protocols to be used for more intuitive JSON/XML >> representations >> - Custom/specific assignment operator for Decoder to capture desired type >> without requiring said type to be specified in decode(type:forKey:) calls >> >> -DW > > 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. > > It’s not a goal to rewrite Foundation from scratch in Swift. All Swift apps > that are running out there today are in fact using a combination of Swift, > Objective-C, C, C++, various flavors of assembly, and more. The goal is to > present the existing API of Foundation in a way that fits in with the > language today while allowing us to iteratively improve it over time. > > - Tony > >> >>> On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hi everyone, >>> >>> Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). >>> I’m back again with more information on another part of our plan to >>> integrate Foundation API into Swift: dropping the NS prefix. >>> >>> When we originally proposed this as part of the API guidelines document >>> (SE-0023, >>> https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md>), >>> we took a very broad approach to which classes would drop their prefix. >>> This time, we’ve narrowed the scope considerably, plus taken advantage of >>> the ability to nest types inside classes to further reduce the possibility >>> of introducing conflicting names. >>> >>> I’ve written up a draft of the proposal, which includes an extensive >>> section on motivation plus a list of changes. Please take a look and let me >>> know what you think. We’ll start a formal review period soon. >>> >>> https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md >>> >>> <https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md> >>> >>> Thanks again for your help, >>> - Tony >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
