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

Should transitive mixins be taken into account in @adt? #1312

Open
kubukoz opened this issue Nov 23, 2023 · 1 comment
Open

Should transitive mixins be taken into account in @adt? #1312

kubukoz opened this issue Nov 23, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@kubukoz
Copy link
Member

kubukoz commented Nov 23, 2023

If you use @adt and all of the members apply a mixin directly, you get a sealed trait that also extends that mixin:

$version: "2"

namespace input

use smithy4s.meta#adt

@adt
union Items {
  s1: Item1
  s2: Item2
}

@mixin
structure HasStuff {
  stuff: String
}

structure Item1 with [HasStuff] {}
structure Item2 with [HasStuff] {}

generates an Items that starts with:

sealed trait Items extends HasStuff with scala.Product with scala.Serializable {

However, if you insert a mixin between ≥1 of the members and the desired mixin:

$version: "2"

namespace input

use smithy4s.meta#adt

@adt
union Items {
  s1: Item1
  s2: Item2
}

@mixin
structure HasStuff {
  stuff: String
}

+ @mixin
+ structure HasHasStuff with [HasStuff] {}

- structure Item1 with [HasStuff] {}
+ structure Item1 with [HasHasStuff] {}
structure Item2 with [HasStuff] {}

then you don't see HasStuff in the trait definition:

sealed trait Items extends scala.Product with scala.Serializable {

Should this be supported by "flattening" the mixin dependencies, or should the models be updated to avoid transitive mixins if we want to use @adt as designed?

@kubukoz kubukoz added the enhancement New feature or request label Nov 23, 2023
@kubukoz
Copy link
Member Author

kubukoz commented Nov 23, 2023

Worth pointing out: the subtypes of Items all inherit HasStuff anyway, it's just that Item1 does so indirectly:

trait HasHasStuff extends HasStuff {
  def stuff: Option[String]
}

//...
case class Item1(stuff: Option[String] = None) extends Items with HasHasStuff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant