I remain a fan of adding 'namespace' to the language.
In the meantime I'll continue using the enum static member approach. But I
would love to have something semantically cleaner.
> El ene. 30, 2017, a las 3:09 PM, Robert Widmann via swift-evolution
> <swift-evolution@swift.org> escribió:
>
> 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) schrieb:
>>
>>> 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?
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
