Hi Tony, Thanks for the response! As Kevin said:
“And if done right, the swiftified types can operate without Foundation at all” This is why I think DispatchData would be superior to NSData, as NSData brings along all the rest of Foundation, whereas the entire Dispatch library looks like a great fit for Swift. In fact, won’t Foundation require Dispatch as a dependency? So there’s already a doubling there if it is. I think Dispatch is much more native than Foundation, and would vote to have its Dispatch- prefixes removed rather than Foundation remove its NS- ones. Patrick > On 13 May 2016, at 5:06 AM, Tony Parker <anthony.par...@apple.com> wrote: > >> >> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I second Matthew’s points. I believe dropping NS- is more harmful than >> helpful, especially for the future. People have been using Foundation with >> the prefix for decades, so I don’t think there’s a longing need that will >> make using it in Swift unbearable. It has an older Objective-C flavoured >> approach, relying heavily on classes, run loops, key value observing (e.g. >> NSOperation), exceptions, and notifications. I think its philosophy will >> stand out more than its NS- prefix. Even if many classes become value types, >> it feels more like a port. >> >> I think for something to be so central as the recommended ‘foundational’ >> library for Swift, it carries too much baggage, which is unfortunate in the >> light of Swift’s radical eagerness to reject unnecessary legacy. >> >> Many Foundation classes expect NSObject subclasses for delegates and for key >> value coding & observing. Key value observing requires on-the-fly >> subclassing at run time, something which goes strongly against Swift’s >> philosophy AFAIK. >> >> Foundation is in some cases a wrapper around underlying technologies such as >> GCD, because years ago an Objective-C wrapper was seen as a more friendly, >> more safe, and a more familiar object-oriented approach. With Swift we have >> the power to make those technologies themselves more friendly, safe, and >> familiar with modernisations such as the current proposal for libdispatch. >> Extensions allow us to add properties and methods directly to the native >> types. >> >> NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable >> state. >> >> I think removing the prefixes will take valuable real estate for types such >> as ‘URL’ and ‘Data’, which instead can have new replacements made, focused >> on the use-cases of only Swift. I think DispatchData could be a fine choice >> for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin. >> > > Perhaps you missed it, but SE-0069 adds corresponding value types for URL and > Data, among others. > > - Tony > >> I fully support the idea of improving Foundation, and of there being a >> Linux-compatible version. I don’t support it being as first class as the >> standard library or libdispatch, and don’t support removing the NS prefixes. >> >> Patrick >> >> >>> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> What is your evaluation of the proposal? >>> I very much support hoisting types, updating enumerations, and updating the >>> NSStringEncoding constants. >>> >>> I do not support dropping NS on type level names. Dropping the 2 character >>> prefix is a very small benefit and it comes with very real costs. I >>> believe unprefixed top level names should not be taken without a manual >>> review of the API design. >>> >>> Types which will be value types in the future are obvious candidates for >>> redesign but are not the only types whose API would benefit by human >>> consideration and Swiftification. Keeping the NS prefix until this happens >>> recognizes that the Swiftification of Foundation is a work in progress. It >>> will give us more options in the future that don’t involve breaking >>> changes. >>> >>> It will also serve as a signal to developers about what kinds of APIs >>> should be considered idiomatic in Swift. If we want developers to learn >>> how to distinguish idiomatic Swift, our API guidelines, etc from >>> Objective-C mappings we need to provide some cues. I believe name prefixes >>> are a good way to do this. >>> >>> I hope that we will move forward with most of this proposal while keeping >>> the NS prefix for top-level names. >>> >>>> Is the problem being addressed significant enough to warrant a change to >>>> Swift? >>> Yes, but we need to do this carefully, deliberately and in a way that we >>> won’t regret in the future. I believe several parts of the proposal are >>> warranted, but the namesake “drop NS prefix” portion should deferred until >>> each type receives manual consideration and possibly redesign. >>> >>>> Does this proposal fit well with the feel and direction of Swift? >>> Mostly yes. However, taking top-level unprefixed names without a process >>> of Swiftification does not. >>> >>>> If you have used other languages or libraries with a similar feature, how >>>> do you feel that this proposal compares to those? >>> I think this question is N/A for this proposal. >>> >>> I hesitate in saying this, but I think the best comparison to consider is >>> the origin of Foundation and Cocoa themselves. They are fantastic >>> Objective-C APIs. If they had originated by wrapping pre-existing APIs >>> written in a different language with different idioms and then >>> incrementally enhanced I wonder if they may have been less fantastic. >>> >>> I believe reserving unprefixed top-level names for manually designed, >>> idiomatic types is the path for Swift that avoids this risk altogether and >>> gives us the best chance possible at an incredible, idiomatic set of >>> libraries. >>> >>>> How much effort did you put into your review? A glance, a quick reading, >>>> or an in-depth study? >>> I participated in the discussion, read the proposal, and carefully >>> considered the consequences of each piece. >>> >>>> More information about the Swift evolution process is available at >>>> >>>> https://github.com/apple/swift-evolution/blob/master/process.md >>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>> Thank you, >>>> >>>> -Doug Gregor >>>> >>>> Review Manager >>>> >>>> _______________________________________________ >>>> swift-evolution-announce mailing list >>>> swift-evolution-annou...@swift.org >>>> <mailto:swift-evolution-annou...@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution-announce> >>> >>> _______________________________________________ >>> 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 <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
