[swift-evolution] [Discussion] Namespaces

Fri May 20 14:48:11 CDT 2016

We've been discussing some thing like this on another thread about
protocols and this looks like a great solution to the problem
expressed there with a very simple change in syntax (and no new
keyword involved). I'd like to see this turned into a separate
proposal (since I'm new on the group and lack the experience, I'm not
the most suitable person to write).

I agree with others that we can nowadays subvert the purpose of an
existing construct of the language to simulate a namespace and I
believe most people here agree that's not the best way to work but
that's what we have now. I think that's why we're here discussing the
idea of namespaces (or submodules, could someone disambiguate them,
please?).

On 20 May 2016 at 12:45, Matthew Johnson via swift-evolution
<swift-evolution at swift.org> wrote:
>
> On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution
> <swift-evolution at swift.org> 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.
>
>
> This is totally orthogonal to namespaces.  C# provides a mechanism to
> clarify implementation of multiple interfaces with the same requirements and
> it has nothing to do with C# namespaces.  For example, it might be possible
> to just prefix member declarations with the name of the protocol.  These
> implementations would not be visible via the primary type interface.
>
> struct Foo : A, B {
>   typealias A.Thing = Int
>   typealias B.Thing = Bar
>   func foo(x: Int) { }
>   func bar(x: String) { }
> }
>
> We could also allow you to omit the protocol-specific declaration for one of
> the conflicting protocols if you wanted that to be visible through the
> interface of your concrete type.
>
> struct Foo : A, B {
>   typealias A.Thing = Int
>   func foo(x: Int) { }
>   func bar(x: String) { }
> }
>
> The same mechanism could work for any members (properties, methods, etc).
> In this case, `foo` is scoped specifically to the implementation of `A` even
> though it is not resolving any ambiguity.  It is not visible via the
> interface of the concrete type `Foo`.
>
> struct Foo : A, B {
>   typealias A.Thing = Int
>   func A.foo(x: Int) { }
>   func bar(x: String) { }
> }
>
>
> Best,
> Austin
>
>
> On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution
> <swift-evolution at swift.org> 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 (daniel_dunbar at apple.com)
> 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
> <swift-build-dev at swift.org> 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
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
> _______________________________________________
> 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
>