On 20 May 2016 at 12:45, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 20, 2016, at 10:21 AM, Austin Zheng via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@apple.com <mailto:daniel_dunbar@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@swift.org <mailto:swift-build-dev@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:
[swift-build-dev] SwiftPM Xcode Integration
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution