[swift-evolution] [Discussion] Namespaces

Austin Zheng austinzheng at gmail.com
Fri May 20 11:14:18 CDT 2016 

Yes. In this case you are basically telling the compiler which of the two foo()s you want to use to satisfy the protocol requirement, and which is just another method that happens to also be named foo().

Austin

> On May 20, 2016, at 9:09 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> But this works:
> 
> protocol A {
>  associatedtype Thing
>  func foo(x: Thing)
> }
> 
> protocol B {
>  associatedtype Thing
>  func foo(x: Thing)
> }
> 
> struct Foo: A,B {
>  typealias Thing = String
> 
>  func foo(x: Int) { }
>  func foo(x: String) { }
> }
> 
> or this also works:
> 
> struct Foo: A,B {
>  typealias Thing = Int
> 
>  func foo(x: Int) { }
>  func foo(x: String) { }
> }
> 
> 
> On 20.05.2016 18:21, Austin Zheng via swift-evolution 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:
>> 
>> protocolA {
>>  associatedtypeThing
>>  funcfoo(x: Thing)
>> }
>> 
>> protocolB {
>>  associatedtypeThing
>>  funcbar(x: Thing)
>> }
>> 
>> structFoo : A, B{
>>  funcfoo(x: Int) { }
>>  // Error: type 'Foo' does not conform to protocol 'B'
>>  // protocol requires function 'bar' with type 'Thing'
>>  funcbar(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
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto: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 <mailto:daniel_dunbar at apple.com>
>>> <mailto:daniel_dunbar at apple.com <mailto: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 <mailto:swift-build-dev at swift.org> <mailto:swift-build-dev at swift.org <mailto: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 <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 <mailto:swift-build-dev at swift.org> <mailto:swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>>
>>>>> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
>>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/5d66aee2/attachment-0001.html>

More information about the swift-evolution mailing list