Proposal for modular assembly of services in container about swinject

[yoichitgy]

Thank you for your idea to add the feature! It is convenient and helpful for users who have used Typhoon or another DI framework supporting the assembly feature (if exists). The implementation plan is perfect👍

What I am thinking about adding a new feature is structuring Swinject project. When I got PR #14, I thought extended features should be in another repository to organize the project. I was also thinking to make a repository for SwinjectStoryboard. However, Apple introduced their own Swift Package Manager with source layouts for modules. Now I think it's good to follow their source layout convention like this:

Swinject repository root
  |- Sources
  |   |- Core
  |   |- Assembly
  |   |- SwinjectStoryboard (if possible because it contains Objective-C code)
  |- Tests
      |- Core
      |- Assembly
      |- SwinjectStoryboard (if possible because it contains Objective-C code)

What do you think about the source layouts in a single repository or multiple repositories to add the assembly feature?

(FYI: Linux target ignores SwinjectStoryboard by adding #if os to the source code.)

[mowens]

Good question. Be it that SPM is still so new (doesn't even support iOS, watchOS, or tvOS yet...) I believe we will see many improvements to its API over the next year. With that said the Source layout structure is probably a better idea compared to separate repos at this time. This would also make supporting CocoaPods very easy with subspecs (not so much for Carthage as now you have to maintain a separate build target for each sub-directory for each platform, but eh what can ya do)

Likely the submodules would need better naming to prevent conflicts as Core and Assembly are very generic. So would probably need to prefix Swinject to each submodule since you cannot specify this in the Package definition: SwinjectCore, SwinjectAssembly etc.. This is obviously very verbose but looks like a necessary requirement for SPM in its current state.

re: containing Objc code
This too I am very curious to see how this gets handled by Apple/Community. While Swift is awesome, many applications require Objc code, however I don't see SPM supporting Objc ever. Maybe there will be some plugin that will support xcodebuild to support Objc but who knows.

[yoichitgy]

Thanks Mike. Now I'm confident to go with the single repo. I'm going to start renaming the source and test directories to try SPM. I won't make submodule directories for now to see more new information or discovery about SPM.

You can implement the assembly feature without modifying the existing code, can't you? Just to prepare the submodule layout in the future. I think, even if something should be added to Container, it can be implemented in a new file with an extension to Container.

I am curious to see the Objc things too. We should watch. Another curiosity is Apple has decided to implement Foundation in Swift. (Core)Foundation was implemented in C with toll free bridge to Objective-C. Probably UIKit will replace its dependency on CoreFoundation to Swift Foundation.

[mowens]

@yoichitgy Yea the modular concept I am proposing will not required any changes to the existing structure. 👍

I will go ahead with the proposal and submit a feature branch. We can discuss merge approaches when the time comes 😃

[yoichitgy]

@mowens I added milestones to release the version 1.0.0 since we decided to manage Swinject in the single repo.
https://github.com/Swinject/Swinject/milestones

• v1.0.0-beta.3: Planned for Issue #38 (a small breaking change). If you have an opinion to #38, it's welcome.
• v1.0.0: Just wait for a week after the small breaking change to see no one complains.

The assembly feature can be included in v1.0.0-beta.3 or v1.1.0 when you finish the implementation😃

[yoichitgy]

Implemented by PR #39.