I'm pretty sure he meant "cross dependencies"

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

Reply via email to