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

[Gwendal Roué]

> Le 5 févr. 2016 à 19:22, Erwin Mazariegos via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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 is a very interesting topic.

I personally don’t use any prefix, but I’m still very careful to avoid names that are too general.

Looking at the main public types of my http://github.com/groue/GRDB.swift (I mean the types that the library user is likely to write in her own code, not the types of temporary values that are usually not written thanks to the Swift type inference), you should be able to guess what the library is about:

Concrete types:
- Configuration
- DatabaseQueue
- DatabaseMigrator
- Record
- Row
- SQLColumn

Errors:
- PersistenceError
- DatabaseError

Protocols:
- DatabaseValueConvertible
- Persistable
- RowConvertible
- TableMapping

The only exceptions are Configuration and Row. I did not feel like I should have named them more precisely because both types are very locally and contextually used. Conflict with user types is possible, but an explicit scoping with the module name is not too costly. That’s a feeling I can rationalize, but mainly it has not been (yet) contradicted by experience.

Record and Persistable are arguably database-ish enough for being kind of self-documenting without any further prefixing.

So, no, I don’t think prefixes are mandatory, or even should be generally recommended. Third-party libraries need their author to avoid likely naming conflicts. BTW, it’s an interesting sub-topic of the discussion about the very general Either and Result types: I can understand why some don’t feel well when they expose such a type in their library, and why they ask for a standard one.

Now, Foundation is a different story, because both Foundation and the Swift Standard Library want to provide basic needs. I would not be disappointed if Foundation would keep the NS prefix, so that the Swift Standard Library has room to expand. Just as Set was eventually introduced as an alternative to NSSet, regular expressions, paths manipulation, trees, etc. are all basic types that will be happy having a blessed Swift version in the future.

Gwendal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160205/8b59c034/attachment.html>