> On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution > <[email protected]> wrote: > > 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.
Why not use Car.List and Animal.List when its unclear from context? With Swift’s type inference you don’t often need to specify types anyway so your editor will know which list type you’re using based on how you obtained it. That said it does depend on the purpose of each List; do they have any commonality? They could for example both be generic List implementations, but were never factored out into a common module. If however they are specialised constructs specific to cars or animals, then the prefix may make most sense. For example, in the libdispatch thread the naming of Dispatch.DispatchQueue was queried, however this isn’t a general purpose queue type, it’s more specialised than that, so a name of “Queue” doesn’t convoy enough information, just as List might not. But it depends on what it actually does, which a basic example tends not to include ;) Anyway, I’m +1 for namespaces everywhere, some names can be common. For example Node could be related to trees, physics engines and all sorts of constructs. “Node” may be a perfectly fine name for these. That said, these are sometimes tied to specific types in which case nesting them may make more sense, which I believe is already being addressed (currently we can’t nest generic types)? It’s certainly not as simple as it can appear! _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
