Good example, +1 for namespaces in swift.
On Fri, May 20, 2016 at 4:21 PM, Austin Zheng via swift-evolution < [email protected]> wrote: > I think namespaces are definitely worth exploring. > > Here's something that might be interesting to research. Right now, you can > have two protocols that have associated types with the same name. If you > adopt both protocols, you have to make the associated types the same, even > if they really don't have anything to do with each other. I think this > might be a good argument for how namespaces can make your code more > expressive: > > protocol A { > associatedtype Thing > func foo(x: Thing) > } > > protocol B { > associatedtype Thing > func bar(x: Thing) > } > > struct Foo : A, B { > func foo(x: Int) { } > // Error: type 'Foo' does not conform to protocol 'B' > // protocol requires function 'bar' with type 'Thing' > func bar(x: String) { } > } > > In this example, I want to use "Int" for A's Thing type, and "String" for > B's Thing type, but I can't. > > Best, > Austin > > > On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution < > [email protected]> wrote: > > I want to revive this topic. > > Is there any technical reason why we can’t have namespaces in Swift? I’ve > found just a few threads about namespaces, but most of them had arguments > to use modules instead. > > I’m fine with modules but they just don’t serve everything I would want > to. I can’t enforce the developer to use the modules name if there is no > naming conflict. > > I asked in the SwiftPM mail list for a easier Xcode integration of > modules, but the response is exactly the opposite for using modules for > namespaces (read below). > > If I’m building one huge project I don’t want to build a lot of different > modules just shiny namespaces and clean code. > > So I ask the community again why can’t we have optional namespaces? > -- > Adrian Zubarev > Sent with Airmail > > Am 19. Mai 2016 bei 22:33:19, Daniel Dunbar ([email protected]) > schrieb: > > Right now modules are most appropriately used at the same granularity that > frameworks or shared libraries would be used in C/Obj-C/C++. This is the > situation for which the variety of access control modifiers in Swift and > things like Whole Module Optimization were designed for. While there are a > lot of reasons to like modules as a way to provide namespaces, they really > haven't been designed to provide these very fine grained namespaces. > > My guess is that the right answer here doesn't really involve the Xcode > integration, but rather figuring out the right way that these concepts fit > into the language in a first class way. I would expect concepts like > submodules or namespaces to be language concepts that Xcode just exposes, > not something that was coupled together. > > - Daniel > > On May 18, 2016, at 12:37 PM, Adrian Zubarev via swift-build-dev < > [email protected]> wrote: > > I’d like to discuss an idea that will make development in Xcode easier. I > assume that SwiftPM will see its Xcode integration when the final version > will be released. > Problem I’ll try to describe is mostly about namespaces. Right now some > people abuses enums, struct or classes to create a namespace for a specific > need. > > class Reference { > class String { … } > class Character { > enum Error { … } > } > > private init() {} > } > > This will create a pseudo namespace for the nested types: > > * Reference.String > * Reference.Character > * Reference.Character.Error > > One could argue of using modules instead of abusing a class here, which is > a great argument. > > The problem that comes to my mind here is that we will have to create > subprojects inside our main project file and using the references to them > just to achieve that shiny namespace. > One could also use SwiftPM, which is awesome, but there is a need to > re-build the module if any changes have been done. As soon as we’ll create > some complex dependencies between different modules this will get messy. > > Before posting here I asked Joe Groff if there is any mailing list I can > use to discuss my idea. He told me this might be a good place, because I > was referring to the package manager. Then I’ve done my research to not > create any redundant thread, but I only found one topic about the > integration of SwiftPM in Xcode: > https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html > > So here are my thoughts about a deeper integration of SwiftPM here: > > - What if Xcode will introduce two new types of groups (the folder color > could be orange like Swift for example, or even contain the bird icon). > - These groups are analogous to already existing group types except > they’ll represent Swift modules / packages > - Basically we’ll have a single project file with multiple modules, where > these modules should only exist inside that project (this is my own need > right now) > - Such a package / module group will have a configurable utilities, where > one could configure the modules > - This will reduce the re-building process, allow us to keep everything > (not only .a or we’ll be able to hide .a files and just keep the > sourcefiles inside such groups) inside a single project, *gain the shiny > namespaces like above*, and make the file management way easier > - This also should allow us create cross-dependencies if there is a good > need for that in our project > > + MainProject > | > +—Reference (module) > | > +—+— Magic (module) > | > +— SomeSubMagic (module) > > We could easily create cross dependencies between modules here by just > using the modules names and the types they provide. > > // SomeSubMagic is a sub module of Magic > class SomeSubMagic { > var magic: Magic // referring to its parent module > } > > What do you think about this? > > -- > Adrian Zubarev > Sent with Airmail > _______________________________________________ > swift-build-dev mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-build-dev > > > _______________________________________________ > 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
