Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add example tool for "dependency tightness" #43

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

keith
Copy link
Member

@keith keith commented May 30, 2023

This tool uses to index to determine how many reference a module has on
its dependencies. It outputs json formatted as:

{
  "A": {
    "B": 5,
    "C": 1
  }
}

Which indicates the module named A has 1 reference to something
defined in C and 5 references to things defined in B.

This tool uses to index to determine how many reference a module has on
its dependencies. It outputs json formatted as:

```json
{
  "A": {
    "B": 5,
    "C": 1
  }
}
```

Which indicates the module named `A` has 1 reference to something
defined in `C` and 5 references to things defined in `B`.
@maxwellE
Copy link
Contributor

Could this be used to find the inverse? In a target can we determine which definitions are the easiest to extract?

@keith
Copy link
Member Author

keith commented May 30, 2023

hrm probably. can you provide an example?

I think with a similar tool you could definitely find cases where a definition in 1 module is only used in another module so it should likely be moved there

@maxwellE
Copy link
Contributor

Its tricky because what I have working locally has to parse raw USRs to determine what a symbol belongs to (unless I am holding it wrong)

@maxwellE
Copy link
Contributor

hrm probably. can you provide an example?

I think with a similar tool you could definitely find cases where a definition in 1 module is only used in another module so it should likely be moved there

Basically I want a linear path of files that can be moved from one target it its next most adjacent target based on the number of inner references of a file to the rest of its target

@keith
Copy link
Member Author

keith commented May 30, 2023

Its tricky because what I have working locally has to parse raw USRs to determine what a symbol belongs to (unless I am holding it wrong)

In this case you don't need to parse the USR because you can just collect all definitions and at that point you know what module they're defined in from the index unit.

Basically I want a linear path of files that can be moved from one target it its next most adjacent target based on the number of inner references of a file to the rest of its target

yea i think that's definitely possible with something like this. I think it would be a matter of tracking what modules reference what USRs and if there is only 1 that isn't where the definition is, it can be moved.

@keith
Copy link
Member Author

keith commented May 30, 2023

here's an example #44

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants