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 < [email protected]> 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 < > [email protected]> 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 ( > [email protected]) 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
