[swift-evolution] The lack of namespaces is leading people astray

Robert Widmann devteam.codafi at gmail.com
Mon Jan 30 14:09:02 CST 2017


I submitted a proposal with TJ a while ago that tried to address this comprehensively because the trouble is if you just want submodules you have to define how our current penta-scheme of access control interacts with each level or do away with a few of them to make some simplifying assumptions.  It also raises an ambiguity with qualified imports that has to be worked out.

> On Jan 30, 2017, at 9:00 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> If I remember correctly it has been said that we don't need namespaces in favor of submodules, which schould solve these issues.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 30. Januar 2017 um 14:55:31, Tuur Anton via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
> 
>> The lack of namespaces is making people create all kinds of "design patterns".
>> 
>> struct API {
>>     static let endpoint = "http://example.com/api <http://example.com/api>"
>> }
>> 
>> Here is an "improvement" to the above "design pattern" to prevent instantiating API:
>> 
>> struct API {
>>     private init() {}
>>     static let endpoint = "http://example.com/api <http://example.com/api>"
>> }
>> 
>> Finally, here is another "improvement" that uses enum instead of struct to avoid having to write the private initializer:
>> 
>> enum API {
>>     static let endpoint = "http://example.com/api <http://example.com/api>"
>> }
>> 
>> I doubt any of you find this beautiful. Yet these "design patterns" (just hacks IMO) are spreading like the plague because of the lack of namespaces.
>> 
>> What do you think?
>> 
>> _______________________________________________
>> 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/20170130/9b001352/attachment.html>


More information about the swift-evolution mailing list