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

Imports API #45

Merged
merged 3 commits into from
Apr 20, 2020
Merged

Imports API #45

merged 3 commits into from
Apr 20, 2020

Conversation

travisbrown
Copy link
Owner

@travisbrown travisbrown commented Apr 18, 2020

This PR includes a few API changes for the imports module that I thought we could get in before 0.2.0, primarily with the goal of minimizing our binary compatibility obligations in future releases.

I've promoted a couple of types that were previously defined in package-private objects but were also exposed in public method signatures in other places, and which felt like they should be in the public API (given usage in tests, etc.):

  • ResolveImportsVisitor.ImportContext is now ImportContext.
  • Caching.ImportsCache is now ImportCache (I've depluralized it for consistency).

I've made a few things that were previously case classes (like ResolveImportsVisitor and NoopImportCache) not case classes, since they don't really need to be, and since case classes with type class constraints are kind of weird (e.g. it's not really clear what equality should mean for two ResolveImportsVisitor values with different Fs or different clients or Sync instances).

I've added a new ResolveImports object that provides a non-enrichment-method-based version of the top-level API, providing two methods (essentially Expr => F[Expr] and (ImportCache, Expr) => F[Expr]). This allows us to avoid using ResolveImportsVisitor directly in tests, which feels a little better to me. I've added an Ops value class for the resolveImports enrichment method there (instead of an implicit class in the package object), since this keeps similar concerns in the same place, and is closer to the pattern used by Cats, etc.

I've made ResolveImportsVisitor and a couple of other things properly private instead of package-private, since this frees them up from binary compatibility concerns (since Scala's access modifiers are a terrible mess and package privacy is just public from the JVM's point of view).

I've also changed CORSComplianceCheck to CorsComplianceCheck for consistency with most other acronym-including names in the project (like JsonConverter, YamlConverter, etc.; I also went ahead and changed a couple of instances of CBORX to CborX here as well).

@travisbrown
Copy link
Owner Author

@TimWSpence I'm thinking of two additional changes:

  • Rename the new ResolveImports (which was an abbreviation of ResolveImportsVisitor) to Resolver, so we have org.dhallj.imports.Resolver following the pattern of org.dhallj.yaml.YamlConverter, org.dhallj.parser.DhallParser, etc.
  • Move the enrichment method conversion to org.dhallj.imports.syntax._, following the rule from Cats and other Scala modules in this package that enrichment method imports are always flagged by a syntax package. (At some point we could also add a Cats-style syntax.all._ import.)

What do you think?

Copy link
Collaborator

@TimWSpence TimWSpence left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@travisbrown travisbrown merged commit 558f55c into master Apr 20, 2020
@travisbrown travisbrown deleted the topic/imports-api branch April 21, 2020 11:16
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.

2 participants