[swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Patrick Smith]

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.

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 at 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-announce at swift.org <mailto:swift-evolution-announce at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/30fe3e2b/attachment.html>