Open
Conversation
The `PortSet` and `PortMap` types don't carry a real meaning on their
own. Their purpose is defined at locations where they're used, such as
`Container.ExposedPorts` or `Container.PortBindings`.
Their documentation also shows this;
// PortSet is a collection of structs indexed by [PortRangeProto].
// PortMap is a collection of [PortBinding] indexed by [PortRangeProto].
Which, almost literally, describes what a map is. Substituting the types
for their implementation doesn't lose any meaning;
// map[PortRangeProto]struct{} is a collection of structs indexed by [PortRangeProto].
// map[PortRangeProto][]PortBinding is a collection of [PortBinding] indexed by [PortRangeProto].
Neither type has any special handling connected to them (no methods or
otherwise), so they are just maps with a fancy name attached. Worse,
using the extra indirect induces cognitive load; it's not clear from
the type that it's "just" a map, indexed by `PortBinding`, and it's
not clear what (kind of) values are in the map.
There are cases where having a type defined can add value to provide
a more in-depth description of their intent, but (as shown above) even
that is not the case here.
I'm considering these types to be premature abstraction with no good
value. As they are a "straight" copy of a map with the same signature,
replacing these types preserves backward compatibility; existing code
can assign either a `PortSet` or `PortMap`, or a `map[PortRangeProto]..`
with the same signature, but we can deprecate the types to give users
a nudge to use a regular map instead. The following shows that they are
interchangeable;
type config1 struct {
ExposedPorts container.PortSet
PortBindings container.PortMap
}
type config2 struct {
ExposedPorts map[container.PortRangeProto]struct{}
PortBindings map[container.PortRangeProto][]container.PortBinding
}
var (
ports map[container.PortRangeProto]struct{}
portBindings map[container.PortRangeProto][]container.PortBinding
ports2 container.PortSet
portBindings2 container.PortMap
)
_ = config1{
ExposedPorts: ports,
PortBindings: portBindings,
}
_ = config1{
ExposedPorts: ports2,
PortBindings: portBindings2,
}
_ = config2{
ExposedPorts: ports,
PortBindings: portBindings,
}
_ = config2{
ExposedPorts: ports2,
PortBindings: portBindings2,
}
Signed-off-by: Sebastiaan van Stijn <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
PortSetandPortMaptypes don't carry a real meaning on their own. Their purpose is defined at locations where they're used, such asContainer.ExposedPortsorContainer.PortBindings.Their documentation also shows this;
Which, almost literally, describes what a map is. Substituting the types for their implementation doesn't lose any meaning;
Neither type has any special handling connected to them (no methods or otherwise), so they are just maps with a fancy name attached. Worse, using the extra indirect induces cognitive load; it's not clear from the type that it's "just" a map, indexed by
PortBinding, and it's not clear what (kind of) values are in the map.There are cases where having a type defined can add value to provide a more in-depth description of their intent, but (as shown above) even that is not the case here.
I'm considering these types to be premature abstraction with no good value. As they are a "straight" copy of a map with the same signature, replacing these types preserves backward compatibility; existing code can assign either a
PortSetorPortMap, or amap[PortRangeProto]..with the same signature, but we can deprecate the types to give users a nudge to use a regular map instead. The following shows that they are interchangeable;- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)