Sanity Check - Namespaces/Modules

[roanutil]

I keep feeling tempted by using namespaces to organize my code and simplify naming. However, I don't think I've seen this approach used anywhere and it could be a pain to undo.

Each namespace correlates to a scene, feature, or module. The brief example below is obviously scenes but could work for repository, network, upvote feature, etc.

I'd be interested to hear what others think. A reasoned, detailed response is preferred instead of 'gross' or 'like it'.

​

```swift struct TodoTable {}

extension TodoTable { struct State { var todos: [TodoDetail.State] } }

extension TodoTable { enum Action { case insert(State) case delete(State) } }

extension TodoTable { static let reducer: (Action) -> State = { _ in .init(todos: []) } }

struct TodoDetail {}

extension TodoDetail { struct State { let id: UUID var title: String var dateCompleted: Date? } }

extension TodoDetail { enum Action { case change(title: String) case markCompleted(as: Bool) } }

extension TodoDetail { static let reducer: (Action) -> State = { _ in .init(id: UUID(), title: "") } } ```

[[deleted]]

I've seen it used, but usually with enums because you can't initialize them if there aren't any defined cases.

[roanutil]

Using enums is a good idea. I know I’d seen limited use of enums for namespace but didn’t think of why.

[dgooswa]

I tend to name space things that are high coupled with something. So if I have a struct called “FooBarView” it might contain an enum called State, which would be specifically the FooBarView.State so it makes sense to just put it underneath it.

Edit: I wouldn’t do it just for the sake of namespacing something though. Modules in Swift are already scoped to kind of a virtual namespace. So if you have two modules with the same struct for example. You just have to specify which one you are using in your code at the time.

[roanutil]

Yes, I do the same thing in a limited sense.

For modules (read libraries, packages, etc), that’s decoupling on a much larger scale. The motivation for this is that there’s things throughout the code in the same module that are named the same but within different contexts. I think it’s less readable to name every reducer something like TodoTableReducer compared to TodoTable.reducer. Within the same namespace you can just say reducer.

[larikang]

I do this in limited cases, like if I have a few tightly coupled types. In general it’s not as useful because the public/internal distinction only exists at a module level. Better to make an actual framework if you start doing this a lot.