This seems like a problem that would be better solved by adopting the Python philosophy that you must provide the full namespace for types, either upon import or explicitly in the code. It also makes searching things in the code easier as it’s clear exactly which namespace each type belongs to.
I don’t see any other motivation for why would you want to force a developer to use the submodule name. If there are no conflicts, why force them to use it? > On May 20, 2016, at 8:54 AM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > Can submodules enforce the developer to use its name ’Submodule.SomeClass’? > Do I have to re-build submodules when I made any changes to them before > building the outside code base? Can they efficiently used for cross decencies > between different modules/submodules? > > —— > Empty enums is an abuse of the language! > > -- > Adrian Zubarev > Sent with Airmail > > Am 20. Mai 2016 bei 17:49:29, Matthew Johnson via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> >> > On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution >> > <[email protected]> wrote: >> > >> >> 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! >> > >> > Absolutely +1 for namespaces. >> > >> > Even if you despise the concept of namespaces that seems like that can be >> > addressed by a project and/or company style guide that explicitly forbids >> > their use. >> > >> > For the people/projects that would embrace namespaces, namespaces would be >> > a godsend. >> > >> > Sure, you can probably pull all kind of stunts to simulate namespaces, but >> > besides creating additional work for the Swift team (and I do not say nor >> > take that lightly), they really need to be supported and implemented at >> > the language/syntax level for first class citizenry. >> >> What benefit do namespaces provide that submodules would not? >> >> > _______________________________________________ >> > 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 > _______________________________________________ > 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
