You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What feature(s) would you like to see in RepoSense
There is currently an AuthorshipFileSegment interface in types/types.ts and a Segment class in utils/Segment.ts. However, as the interface and the class are mostly equivalent, it will be reasonable to remove either of them.
Is the feature request related to a problem?
The interchangeable usage of the Segment Interface and class implies possible inconsistency.
If possible, describe the solution
Remove either the interface or the class and replace all usages of the removed construct. Removing the class seems to have more advantages considering the runtime.
If applicable, describe alternatives you've considered
Removing the interface may also be reasonable as it may allow more flexibility with class methods in a future context.
Remove Segment class, replace with AuthorshipFileSegment
The Segment class and AuthorshipFileSegment interface are equivalent in
their usage and their redundancy seems to be a remnant when the code
was migrated from JS to TS.
Let's remove the Segment class for consistency and to improve runtime
performance.
What feature(s) would you like to see in RepoSense
There is currently an
AuthorshipFileSegment
interface intypes/types.ts
and aSegment
class inutils/Segment.ts
. However, as the interface and the class are mostly equivalent, it will be reasonable to remove either of them.Is the feature request related to a problem?
The interchangeable usage of the
Segment
Interface and class implies possible inconsistency.If possible, describe the solution
Remove either the interface or the class and replace all usages of the removed construct. Removing the class seems to have more advantages considering the runtime.
If applicable, describe alternatives you've considered
Removing the interface may also be reasonable as it may allow more flexibility with class methods in a future context.
Additional context
Discussed in #1969 and #1965.
The text was updated successfully, but these errors were encountered: