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

[Derrick Ho]

If you make a dynamic framework called APIFramework
And add a public class called URL_ME

You can instantiate it with APIFramework.URL_ME() from your project.


I haven't tried to see if this would work with global variables but I
assume it would.
On Mon, Jan 30, 2017 at 3:09 PM Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

> 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) 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 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
>
>
> _______________________________________________
> 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/20170131/08eeb42c/attachment.html>