refactor: codehealth rename types to reflect axis of transformation#1451
Merged
Conversation
this entirely a change for code clarity, because if you read (before
this patch) the `AnyToAnyImporter#import` generic-params you'll see
`To` being passed in as the source of data (what should be a conceptual
"From").
The cause of that confusion is that there's multiple different
orthogonal transformations happening with/around the
`TransferCompatibilityProvider` and its supporting `AnyToAnyImporter`
class and DTP generally:
1. DTP moves data from a Exporter producing models to an Importer
consuming models
1. we have static functions that convert model A to model B (eg: from
Photos model to a Media model via
[`MediaContainerResource::photoToMedia`][pToMedia])
- this is parallel to the `From` and `To` generic params of
[`java.util.function.Function<From, To>`][Function].
1. `TransferCompatibilityProvider` converts *an importer* (via
`AnyToAnyImporter` and a model-transformer like above) from an
importer of one model type to an importer of another model type.
I'm now using the language of "stand-in importer" to indicate which
importer was selected as the input (think the `g` in `f(g(x)`) to
indicate the key moving piece in that last kind of transformation listed
above.
[Function]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/function/Function.html
[pToMedia]: https://github.com/dtinit/data-transfer-project/blob/bca0c7926fb871c7fdd7e206908a87874ec624f2/portability-types-common/src/main/java/org/datatransferproject/types/common/models/media/MediaContainerResource.java#L45
jzacsh
force-pushed
the
refactor-fix-confusing-types
branch
from
45d122b to
cac8470
Compare
jzacsh
changed the title
calumcalder
approved these changes
Apr 9, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
this is entirely a change for code clarity, because if you read (before this patch) the
AnyToAnyImporter#importgeneric-params you'll seeTobeing passed in as the source of data (what should be a conceptual "From").The cause of that confusion is that there's multiple different orthogonal transformations happening with/around the
TransferCompatibilityProviderand its supportingAnyToAnyImporterclass and DTP generally:MediaContainerResource::photoToMedia)FromandTogeneric params ofjava.util.function.Function<From, To>.TransferCompatibilityProviderconverts an importer (viaAnyToAnyImporterand a model-transformer like above) from an importer of one model type to an importer of another model type.I'm now using the language of "stand-in importer" to indicate which importer was selected as the input (think the
ginf(g(x)) to indicate the key moving piece in that last kind of transformation listed above.