Skip to content

Refactor some tuple methods #19032

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

Merged
merged 3 commits into from
Nov 24, 2023
Merged

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Nov 23, 2023

  • Move from Definitions to TypeUtils
  • Unify TypeUtils.tupleElementTypes and Definitions.tupleTypes. They do the same thing.

I'd like to move more things out of Definitions and into TypeUtils and SymUtils. Then I'd like to move these files to the core package, and make their operations accessible automatically by having the companion objects of Types and Symbols inherit from them. This is a first step into that direction.

 - Move from Definitions to TypeUtils
 - Unify TypeUtils.tupleElementTypes and Definitions.tupleTypes. They do
   the same thing.

I'd like to move more things out of Definitions and into TypeUtils and SymUtils.
Then I'd like to move these files to the core package, and make their operations
accessible automatically by having the companion objects of Types and Symbols inherit
from them. This is a first step into that direction.
 = Move to core package. It was for historical reasons in transform because
   it was originally intended as a collection of type operations that were
   were useful in transform phases. But it's now used from everywhere.
 - Make a base class of Types, so that it does not need to be imported explicitly.
 - Move to core package. It was for historical reasons in transform because
   it was originally intended as a collection of type operations that were
   were useful in transform phases. But it's now used from everywhere.
 - Make a base class of Types, so that it does not need to be imported explicitly.

Also: move isDerivedValueClass to SymUtils
@odersky odersky added the backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. label Nov 24, 2023
@odersky
Copy link
Contributor Author

odersky commented Nov 24, 2023

@Kordyjan This is a fairly large refactoring to make functionality more discoverable with less boilerplate in the future. I think it would be good to backport this to LTS so that we don't get too much of a divergence between the two versions.

@nicolasstucki nicolasstucki merged commit 55c2002 into scala:main Nov 24, 2023
@nicolasstucki nicolasstucki deleted the refactor-utils branch November 24, 2023 13:53
@Kordyjan Kordyjan added this to the 3.4.0 milestone Dec 20, 2023
WojciechMazur added a commit that referenced this pull request Jun 26, 2024
Backports #19032 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
@WojciechMazur WojciechMazur removed the backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. label Nov 8, 2024
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.

4 participants