I personally dislike the habit of deliberately naming different classes using
the same name within a single project/module/library, just using different
namespaces - one should be able to deduct from the code *which* class is being
used without excessive checking.
When you have namespaces Car and Animal and each contains a class called List,
IMHO there should be classes CarList and AnimalList. It's more verbose, but you
imediately know which class is being used in opposite of just using List.
I assume you would still stick around with a standalone
`SomeCustomeViewDelegate` protocol rather than use `SomeCustomView.Delegate`
and nest the `Delegate` protocol inside `SomeCustomView`? This isn’t an example
about namespaces but you get the idea.
What looks better to you?
protocol SomeCustomeViewDelegate {…}
or
extension SomeCustomView {
protocol Delegate {…}
}
I don't have much experience with C++ and C#, but sometimes I have to dive into
C# code and you can hear my teeth grind since there is a declaration of a
variable of class List and you have no idea which List is this, since there are
dozens of classes with this name. You don't always have the code in an IDE to
resolve the symbol for you, sometimes you browse it on git, etc.
Which is why I personally find modules sufficient in providing a way to prevent
naming collisions, yet strict enough to discourage the habits of other
languages described above.
In my eyes namespaces in Swift (if we get them) should be optional which will
allow someone write clear code if there is any desire.
For my project I’m working on it’s something like:
Reference.Buffer
Reference.String
Where I’m working with Pointers inside.
If I will use a module for this in my project, there will be a name collision
with String when I forget about `Reference.`.
One can already achieve a pseudo namespaces by abusing structs for example.
struct Namespace {
private init() {}
}
But you still can something like:
extension Namespace { … }
This doesn’t fell right.
Downside of modules in a huge project is that you might need re-build modules
all over again when you changes something. :/
--
Adrian Zubarev
Sent with Airmail_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
