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

[Dan Appel]

-1 for all the reasons given so far. Foundation is not a Swift API and the
NS prefixes help users understand that. Until Foundation gets an API
rewrite that makes it feel native in the Swift ecosystem, it should be made
very clear that it is a legacy API and not necessary following Swift best
practices. I'm actually quite surprised that the Swift team decided to
reimplement Foundation with 100% api compatibility, rather than building a
"new and improved" version from scratch.

On Mon, May 16, 2016 at 6:37 PM Rob Mayoff via swift-evolution <
swift-evolution at swift.org> wrote:

> We (you) shouldn't remove the NS prefixes from most of the classes in
> the proposal. I agree with the reasons the other naysayers have given,
> but I'll try to restate them in my own words.
>
> Swift needs a better namespace/import system before these classes
> should lose the NS prefix. Right now, you cannot just import one name
> from a module. (If you think you can, try typing “import
> Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
> selective about what loses the NS prefix.
>
> For any type, some fraction of programs need to mention the type by
> name in order to justify a prefixless name. What should that threshold
> be? Fifty percent? Ten percent? Five percent? String and Int and a
> bunch of other types in the standard library can pass a reasonable
> threshold. What fraction of programs mention NSTask? NSPort? NSHost?
> NSScanner?
>
> For any name, some fraction of programs would want to use that term
> for a program-specific type different than the Foundation type. What
> fraction is high enough to justify prefixing the Foundation type name?
> E.g. are there enough datebook programs that think "Calendar" should
> mean the user's schedule of events, so that Foundation shouldn't claim
> the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
> "Host"?
>
> What fraction of these Foundation types would have a substantially
> different API if they were designed from scratch in the age of Swift
> with the experience of Foundation? Example: NSDate. Looking at each of
> JodaTime, NodaTime, and boost::date_time, I see a type representing a
> calendar date (e.g. 2016-05-16) with no associated time of day. I've
> seen and answered enough questions on stackoverflow to know that iOS
> programmers want a type like that. A from-scratch Swift date/time
> library would be justified in having such a type, and "Date" would be
> a great name for that type (with a prefix or nested in another type,
> unless Swift gets a better namespace/import system). NSDate represents
> the same thing as CFAbsoluteTime, and should have a name more
> representative of that.
>
> I just don't see the benefit of stripping the NS prefix from most of
> the types in Foundation, given the state of those types and the state
> of Swift.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/2a2d60eb/attachment.html>