I'm still using things like: public /* namespace */ enum MyNamespace { ... } to fake namespaces. Any news about namespace keyword or its possibility of being implemented?
10 Likes
Fake namespaces are discussed to be used in the stdlib
Thank you for the link. But I'm thinking about other scenarios too. Instead of writing this:
public enum SomeCoolService { }
extension SomeCoolService {
public class API {
//...
}
}
To accomplish this:
let api = SomeCoolService.API()
I'd like to write this:
public namespace MyCoolService {
public class API {
// ...
}
}
Or:
public namespace MyCoolService { }
extension MyCoolService { // this as a real namespace, not a enum
public class API { ... }
}
1 Like
I would like namespace since I find enum counterintuitive.
5 Likes
An additional benefit of a namespace keyword is that functions and variables are static by default, because a namespace can't be instantiated:
// current syntax
enum Foo {
static var bar: Bar { ... }
static func baz() { ... }
}
// proposed syntax
namespace Foo {
var bar: Bar { ... }
func baz() { ... }
}
11 Likes
I wonder if the functionality of a 'namespace' is tied together with the namespace keyword in a programming language. I don't like fake namespaces in Swift. Even the WWDC14 presentation had a slide live on stage that said the new programming language Swift included namespaces, but where are they?
Btw. if you nest your types you will probably hit this at some point:
https://bugs.swift.org/browse/SR-631 (The most voted, not ABI related - therefore low priority, issue on JIRA.)
1 Like
I would much rather see sub modules than namespaces and I’m skeptical that it would be a good idea to have both. This makes me very reluctant to see namespaces introduced. I think we need to resolve submodules first and if people still feel namespaces would add something we can revisit the topic in the future.
15 Likes
No objections at all, I also would love to see submodules happen. While writing my previous answer I totally forget about them, glad you remind me about them.
Good point about SR-631. Yep. I had this problem and I had to rethink the architecture I was creating in that occasion.
Well the issue is solvable without restructuring the project, but the solution isn't convenient. You have to shuffle the files in Xcode's compile sources until Xcode is satisfied.
What's the difference between submodules and namespaces?
I took the word namespace because I think it is a more intuitive word. In other worlds (like .NET) there is assembly (something like our Xcode framework/Swift module) and namespace (something like our... no... wait... something like our empty enum).
Do submodules are other concept or simply other name for the namespaces?
I'm asking this because creating other framework projects in Xcode only to have submodules or namespaces will be... Much ado about almost nothing.
I think a namespace with the behaviour of a empty enum + static vars/funcs by default is simple and not hard to implement/learn/use.
2 Likes
Submodules are a pretty deep topic and broad design space. They were discussed quite heavily last year, including the relationship to namespaces. You can find the previous threads by searching the forums: Search results for 'submodules category:18' - Swift Forums.
1 Like
i don’t get how this adds anything that enum can’t already do. you’re just adding another keyword to the language
@taylorswift The problem using enum for this is that semantically its purpose is to be an enumeration and not to fake namespaces. How one explain to other learning the language that in Swift we use enum this way? Also this collateral namespace feature of enum could be removed from the language anytime (and, IMHO, should be removed when namespace is implemented).
3 Likes
@anandabits Thank you for the links. Well... But I stil think that namespace could be one thing and submodule other thing.
@vmartinelli it's possible but I would prefer to wait on namespaces until we have thoroughly vetted the submodule topic and know where that lands. That's not going to happen in the Swift 5 timeframe.
2 Likes
i mean when i was learning the language using enum made perfect sense. types in Swift double as namespaces, and out of the 3 types of types, class, struct, and enum, enum is the most “lightweight” so it makes sense it would be the preferred container if all you wanted was a namespace and nothing else
also in general i’m just against adding more global keywords to the language that serve no purpose
I just saw a talk (i dont think the keynote is online yet) with the lead developer of typescript and he said that with modules, namespaces have less meaning https://www.typescriptlang.org/docs/handbook/namespaces.html
I think I much rather have better module support in Swift than namespaces.
idk what modules are in typescript but Swift’s concept of a “module” is really more in terms of shipping than grouping related functionality. a Swift module is basically what you would call a package in other languages and so they have a concept of versioning, tagging, and ABI boundaries that make no sense to talk about when you’re talking about namespaces
The primary goal of submodules (IMO) is to separate the logical structure and encapsulation afforded by modules from the physical structure (and associated overhead) of a build product.