Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-52582

libdeps graph linter: private that should be public

    • Type: Icon: New Feature New Feature
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Server Development Platform

      from the document:

      This is actually one of the simpler ones. If A declares a private dependency on Z, but use of A’s interface by a client C induces a dependency on symbols from Z, then A’s declaration of the Z dependency should be promoted from private to public. Such a transformation is always safe: no edges are removed, and no other nodes will have their current dependency set reduced.


      There is a subtle angle to this one (of course!): it is possible that use of A’s interface induces symbol dependencies on Z in C not because of the direct use of Z in A’s interface, but because A induces the use of symbols from B, and use of those symbols from B induces the use of symbols from Z. If all of the induced uses of Z in consumers of the A interface can be explained away by other should-be-public dependencies of A (like B), then it makes no difference if Z is public or private in A: B will need to be public in A, and Z will need to be public in B. In such situations, it seems best that if A really does make direct use of Z internally, that it be declared a private library dependency despite the fact that B will drive it through A as public to A’s clients. Otherwise, if B later changed such that it no longer induced a Z dependency on clients of A’s interface, Z would suddenly become flagged as public-should-be-private in A.


      Given that the transformation suggested by the linter is safe and the conditions reasonably easy to understand, it is probably a good candidate for implementation early in the project.

            backlog-server-devplatform [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
            daniel.moody@mongodb.com Daniel Moody
            0 Vote for this issue
            1 Start watching this issue