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

update how mixins and structs with mismatches are handled #425

Merged
merged 2 commits into from
Sep 1, 2022

Conversation

lewisjkl
Copy link
Contributor

Update that will make it so case classes no longer extend mixin-related traits when they contain fields that do not match in type (optional vs. required, etc). See examples in this PR for more cases.

Resolves #422.

)
)
val mixinMembers = mixin.getAllMembers().asScala
mixinMembers.foldLeft(true) { case (state, (memberName, member)) =>
Copy link
Contributor

Choose a reason for hiding this comment

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

ain't that a forAll ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Dammit, yeah haha I'll update

@lewisjkl lewisjkl merged commit 40ead44 into main Sep 1, 2022
@lewisjkl lewisjkl deleted the default-mixin-fix-2 branch September 1, 2022 16:42
daddykotex added a commit that referenced this pull request May 5, 2024
Similar to what was done in #425, I've filtered out the
mixins that have different type than the final shape they're
applied to.

As such, in the example above, `HasName` has a optional name
member where as `Person` inherits the mixin but makes the member
required. The filtering catches that and as a result the mixin is
removed from the list of mixins to add on `Person`.

This behaviour aligns with the behaviour that happens when no `@adt`
trait is added and `Person` is code generated on it's own. In both
cases, now, the trait `HasName` is not extended because the types of
`name` don't align.
Baccata pushed a commit that referenced this pull request May 8, 2024
* Filter mixins that have different types

Similar to what was done in #425, I've filtered out the
mixins that have different type than the final shape they're
applied to.

As such, in the example above, `HasName` has a optional name
member where as `Person` inherits the mixin but makes the member
required. The filtering catches that and as a result the mixin is
removed from the list of mixins to add on `Person`.

This behaviour aligns with the behaviour that happens when no `@adt`
trait is added and `Person` is code generated on it's own. In both
cases, now, the trait `HasName` is not extended because the types of
`name` don't align.
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.

Codegen: mixin with default field causes downstream compilation errors
3 participants