Check fqn prefix for dependencies, not direct match. #5
Conversation
Allows a declared dependency 'a -> b' to satisfy a module dependency 'a.x.y -> b.z'.
…ency crossing that package boundary ie. if you have 'a -> b', you can have a.x import b.y, but only if neither a nor b have dependencies going into or out of them from elsewhere. a -> b, a -> a.x: allow a.x -> b.y a -> b, a.x -> a.y: allow a.x -> b.y a -> b, a.x -> z.x: don't allow a.x -> b.y a -> b, z.x -> b.y: don't allow a.x -> b.y
|
|
||
| bool canDepend(const string client, const string supplier) | ||
| { | ||
| // a -> b allows a.x -> b.y, unless there's a dependency a.x -> [not a].* or [not b].* -> b.y |
There was a problem hiding this comment.
Do we really want this?
If we want to be specific for c with a.x -> c.z and c.z -> b.y, then we can no longer be less specific for a -> b?
There was a problem hiding this comment.
The intuition is that "any arrows that pierce the boundary of a remove the opacity of a". It may be misleading to have an arrow pointing into or out of a in the diagram, and have further modules in a allowed to do undeclared imports anyways.
Besides, you're the one who asked for this. :)
There was a problem hiding this comment.
My idea was: if there are specific dependencies like a.x -> b.y, then the general dependency a -> b (from another diagram) shall be removed from the target dependencies. The remaining target dependencies shall be used to match prefixes of the actual dependencies.
(So a.x -> c.z would not effect a -> b.)
My hope is: the corresponding implementation is much closer to "can still be understood next month" than the current one.
There was a problem hiding this comment.
I think the most important feature of the implementation is understanding what it's supposed to accomplish. I haven't understood that with yours yet.
Allows a declared dependency 'a -> b' to satisfy a module dependency 'a.x.y -> b.z'.