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

Reply via email to