wire.NewSet()
is the perfect terminology. By that definition, this (albeit contrived example) should ideally work:
var Set = wire.NewSet(ProvideFoo, ProvideFoo)
Currently, this fails with a multiple bindings error. While you certainly want to prohibit the application from defining bindings in conflicting ways, automatically deduplicating identical bindings would simplify application development with Wire.
A more interesting example is when you have provider sets at multiple levels of the stack with inter-dependencies:
----------------
/| feature1.Set |\
/ ---------------- \ ----------------
/ ---| library1.Set |
------------ / ---------------- / ----------------
| main.Set | ----| feature2.Set |/
------------ \ ----------------
\
\ ---------------- ----------------
\| feature3.Set |-----| library2.Set |
---------------- ----------------
Without deduplication, main.Set
has to list all of the Sets in the entire application:
package main
var Set = wire.Set(
feature1.Set,
feature2.Set,
feature3.Set,
library1.Set,
library2.Set)
This "top level aggregation" pattern requires knowledge of the entire tree of Sets at the top level, and can be a maintenance hazard as Sets are removed / reconfigured (i.e. dependency rot). This is a common problem with other DI frameworks like Guice.
With deduplication, each Set can be self-contained by including the Sets of their dependencies, even shared ones. Then the top level need only include Sets for its high level features:
package feature1
var Set = wire.Set(..., library1.Set)
package feature2
var Set = wire.Set(..., library1.Set)
package feature3
var Set = wire.Set(..., library2.Set)
package main
var MainSet = wire.Set(
feature1.Set,
feature2.Set,
feature3.Set)
This provides better encapsulation, giving each package the sovereignty to add and remove downstream dependencies without requiring modifications to their upstream dependents.
Long story short: deduplication of identical bindings can allow applications to declare (possibly shared) provider set dependencies, improving encapsulation and making application "wiring" closer to dependency-aware build systems like Bazel.
I hope this provides some good context for this feature request. Thanks!