> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution > <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 > > _______________________________________________ > 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
