Good to know. Maybe it's not namespacing proper, but it's a component in a larger system (which allows disambiguation of ambiguously named types by hierarchical qualification), and should be at least thought about.
Austin > On May 20, 2016, at 8:45 AM, Matthew Johnson <[email protected]> wrote: > > > 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] <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
