> On May 20, 2016, at 11:09 AM, Brandon Knope <[email protected]> wrote: > > I'm pretty sure he meant "cross dependencies”
It’s still unclear to me how namespaces might help in a way that submodules wouldn’t. Can one of you provide an example of the problem you have in mind and how it is solved with namespaces? > > Brandon > > Sent from my iPad > > On May 20, 2016, at 12:06 PM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> >>> On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Can submodules enforce the developer to use its name ’Submodule.SomeClass’? >> >> Ideally we would have flexible import syntax that allows for control over >> *how* names are imported into a lexical context (including the ability to >> import names within a very specific scope if desired). >> >>> Do I have to re-build submodules when I made any changes to them before >>> building the outside code base? >> >> All submodules are part of the same target as the module that contains them. >> >>> Can they efficiently used for cross decencies between different >>> modules/submodules? >> >> Cross decencies? I don’t understand. >> >>> >>> —— >>> Empty enums is an abuse of the language! >> >> But it is a practical and effective one. Introducing a new construct like >> namespaces must carry significant advantages over what is already possible. >> >>> >>> -- >>> 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] <mailto:[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] <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] <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
