[swift-evolution] [Discussion] Namespaces

[Brandon Knope]

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 <matthew at anandabits.com> wrote:
> 
> 
>> On May 20, 2016, at 11:09 AM, Brandon Knope <bknope at me.com> 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 <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>> On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> 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 (swift-evolution at swift.org) schrieb:
>>>> 
>>>>> 
>>>>> > On May 20, 2016, at 10:43 AM, Robert Schwalbe via swift-evolution <swift-evolution at swift.org> 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
>>>>> > swift-evolution at swift.org
>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/18d2b165/attachment.html>