I'm definitely leaning toward submodules too. That seems more "Swifty" to me.
I too would like to see some examples of namespaces in action Brandon > On May 20, 2016, at 12:12 PM, Matthew Johnson <[email protected]> wrote: > > >> 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]> wrote: >>> >>> >>>> On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution >>>> <[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]) 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] >>>> 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
