I have been known to mimic namespaces as well, however now that SPM is here, I no longer see a need for it.
Still, I won’t object to it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 01 Feb 2017, at 06:30, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The lack of namespaces is making people create all kinds of "design >> patterns". >> >> struct API { >> static let endpoint = "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" >> } >> >> 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" >> } >> >> 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? > > Personally, I’m in favor of namespaces, but it’s more of a “seems like a good > idea” thing than “I need this because <reason>”, at least from my PoV. I’m > inclined to just defer to the core team’s judgement on this one. > > On the plus side though, if we ever do get formal namespaces, it should be > relatively simple to search for enums with no cases and give a fixit. > > - Dave Sweeris > > _______________________________________________ > 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