[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift

[Erwin Mazariegos]

The points made by Nate regarding his reasons for keeping the "NS" prefix
for Foundation types resonated with me, but for slightly different reasons.

In particular, where Nate states "Prefix-less Foundation types will blur
the different norms and expectations for Foundation types vs what we have
in the Swift standard library" contrasting Foundation and the Swift
standard library, this is very similar to my concern for being able to
differentiate between Foundation and app-specific custom types.

When working with an app's codebase, it is helpful to immediately be able
to tell where a particular type "comes from". Is this an instance of an
object defined in this app's codebase, or is it a Foundation object? There
are "different norms and expectations for Foundation types" in this
direction as well. Forcing readers of the code to click through to the
object type's definition (or perform a project-wide search) just to
discover the type is Foundation, is wasteful.

Swift's namespacing removes the technical requirement to prefix types as
became the norm in Objective-C. But there remain understandability
requirements that we should maintain.

Broadening the topic of prefixes beyond Foundation, it would be helpful to
keep the convention of prefixing types that are designed to be used as part
of a library, and leaving app-specific (or end-user-developer) types
unprefixed if desired.

Personally I am enjoying the safety of not having to prefix custom types in
my apps. But if I was writing a third-party library, I would want to use a
"signature prefix" on my types. Similarly, the NS prefix should remain on
Apple-supplied Foundation types.

This prefix-for-library-types convention would make it easier to quickly
grasp where a particular piece of functionality in a codebase is coming
from, so we can apply norms and expectations regarding the source.

Removing the NS prefix from Foundation types has large code
understandability/readability costs with little to no benefit for app
developers.



Regards,
----
Erwin Mazariegos
Austin, TX

On Fri, Feb 5, 2016 at 10:54 AM, Michel Fortin via swift-evolution <
swift-evolution at swift.org> wrote:

> Le 5 févr. 2016 à 7:14, David Hart via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> > I agree with most of the proposal except for "Strip the "NS" prefix from
> Foundation APIs”. I strongly disagree with this change for the same reasons
> as Nate:
> >
> > - This change will make Foundation types look Swift native enough to
> confuse some users between the stdlib’s value semantics and Foundation’s
> reference semantics.
> > - The change will complicate the creation of a Swift native foundation
> that uses the power of Swift to provide true value semantics to types that
> need them (URL, Data, CountedSet, etc…)
>
> But there are also many classes that make perfect sense in Swift as a
> class: URLSession, Formatter, UndoManager, UserDefaults, XMLParser, Stream,
> NotificationCenter, RunLoop, etc. What we could do is decide now which
> Foundation classes should stay classes and which should become structs.
> Remove the NS prefix from the former, keep it for the later.
>
> Eventually, classes such as NSCountedSet and NSIndexSet will have a proper
> struct wrapper that will claim the non-prefixed name. But there is no
> urgency in making those wrappers ready for Swift 3 because the class
> remains available.
>
> Anyway, that's what I'd propose. There aren't that many classes in
> Foundation; cases like this can be sorted out manually.
>
> --
> Michel Fortin
> https://michelf.ca
>
> _______________________________________________
> 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/20160205/5f8322d3/attachment.html>