> On May 20, 2016, at 10:27 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > Another use case to consider: code generation. There, namespaces can be > vital; they let you isolate code that you may have no real control over (for > example, data models that correspond to remote services) from the rest of > your code to avoid collisions. In some cases that can be achieved by putting > the shared code in its own module, but if that data description format has > hierarchical namespaces/packages of its own (Google's protocol buffers, for > example), then the lack of namespaces forces the code generator to come up > with contrived schemes for naming nested entities (like the Objective-C > implementation, which uses underscore_delimited_names). The result is that > Swift code using those services would look *very* unnatural.
What benefits do namespaces provide that empty enums and / or submodules do not? This isn’t clear to me and I think it is an essential part of the case that must be made. Nobody is arguing that we don’t need a way to isolate names. The question is whether namespaces are the right mechanism for doing that or not. > > > On Fri, May 20, 2016 at 8:08 AM T.J. Usiyan via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > +1 for namespaces. > > On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution > > <[email protected] <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
