> On May 20, 2016, at 10:21 AM, 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.
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
>> <[email protected] <mailto:[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]
>> <mailto:[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] <mailto:[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
>>>>
>>>> <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] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>>> <https://lists.swift.org/mailman/listinfo/swift-build-dev>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
