Skip to content

Change the way we infer the types of steps arguments #206

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 1 commit into from
May 15, 2021

Conversation

gaeljw
Copy link
Member

@gaeljw gaeljw commented May 1, 2021

This PR significantly changes the way the types of steps arguments are "inferred" by Cucumber Scala.

The main difficulity being generic types like List[Map[String, String]] (used for instance for datatables).

Current situation (Scala 2)

We rely on the scala reflection Manifest mechanism which overcome the JVM type erasure.

In recent Scala 2 versions, Manifests are deprecated but still available. The replacement being TypeTags which could be used in a very similary way.

Future (Scala 3)

With Scala 3, both Manifest and TypeTags are removed with no direct replacement.

I tried to mimic the behaviour by using macros in a previous PR (#186) thanks to a home made library (typetrees). This was working but:

  • it doesn't feel right to have to use macros for our need
  • it hardens maintability as the Scala 2 and Scala 3 code are really different
  • it brings dependence on an "unproven" 3rd party library.

Proposition

This PR changes the way we infer types by using a well-known typeclass mechanism.

Argument of a step must have a type T that conforms to the typeclass Stepable[T]. This typeclass being defined as:

trait Stepable[T] {
  def asJavaType: JavaType
}

Implicit values of Stepable are provided for all non generic types and generic types with less than 10 parameters (any combination of these being possible).

This might sound like we are reducing the possibilities of types allowed in step arguments and it is the case for generic types with more than 9 parameters but:

  1. I don't see many use case for such types
  2. We can always implement other implicit values in the future

TODO

  • Add unit tests on Stepable implicits
  • I will test this PR on our big projects at work to check for undesired side effect.

Additional note: we still need a slightly different code in StepDsl between Scala 2 and Scala 3 but not related to the types of step arguments, only to some construction not allowed anymore in Scala 3 for handling both fn: => Unit and fn: () => Unit.

@gaeljw gaeljw added this to the 7.x milestone May 1, 2021
@gaeljw gaeljw self-assigned this May 1, 2021
@gaeljw gaeljw force-pushed the remove-typetree-tag branch 3 times, most recently from 7334f58 to 20f232f Compare May 15, 2021 14:57
@gaeljw gaeljw force-pushed the remove-typetree-tag branch from 20f232f to 52edabc Compare May 15, 2021 15:09
@gaeljw gaeljw marked this pull request as ready for review May 15, 2021 15:55
@gaeljw gaeljw merged commit 81b6788 into v7.x May 15, 2021
@gaeljw gaeljw deleted the remove-typetree-tag branch May 15, 2021 15:56
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.

1 participant