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

[Haravikk]

> On 5 Feb 2016, at 18:22, Erwin Mazariegos via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

While I agree with this in theory, the problem with prefixing is what to choose; NS is nice and simple so it’s not much of a burden, but how many two letter prefixes can we expect before it gets confusing anyway, or you forget what the prefix is for?

Personally I’d prefer to make sure that Xcode exposes the namespace of a type as clearly as possible, e.g if you hover over the type it should expand to give a fully qualified name in addition to any documentation etc., leaving no ambiguity. In other words I wonder if name clashes is really a naming problem, or if it’s something that a good GUI should be able to handle for us. After all we can’t rely on every developer adding a prefix or suffix, and sometimes that commonly used name just happens to be the most appropriate.

I can’t count the number of times I’ve named something Node because I couldn’t think of anything more relevant, but likewise couldn’t find enough commonality to factor it out into a single type, resulting little nested Node types here and there. At least with the private keyword we can be clear that a developer need search no further, but I think it’s just a problem that can and will occur regardless of guidelines, so the tools need to be able to cope when it does.