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@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@swift.org <mailto:swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
