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

Proposed Fix for issue #668 - convert Gherkin table to List<T> in Scala DSL #669

Merged
merged 2 commits into from
Mar 16, 2014

Conversation

chriswhelan
Copy link
Contributor

Commit messages are hopefully self explanatory.

This allows the handy conversion to List<T> for Gherkin tables to work from the Scala DSL. See the new Scenario and custom object "Cuke" added to the test suite for an example using a Scala class wrapped in a java.util.List<Cuke>.

Ideally I'd like to support scala Lists, but that can wait for a later enhancement.

The previous implementation was using Scala 2.9 reflection via
Manifest[T] to extract the function parameter types using the erasure
method (renamed to runtimeClass in Scala 2.10).

The problem with this approach is that Manifest.erasure provides the
runtime java.lang.reflect.Type, which means the type has been erased of
paramterized type info.

The ParameterInfo class relies on the ParamaterizedType information
to determine how to auto populate Step arguments of type
java.util.List<T>. When using java Lists from the Scala DSL, this logic
would fail.

As ParameterInfo's implementation is entirely based on the Java
reflection API, it makes more sense to use Java reflection in the
implementation of Scala DSL as it will be compatible with the logic in
core.

This change uses Java reflection on the Scala Function objects to
extract the ParameterizedType information, which also simplifies the
code.

The manifest is no longer used by the register method, but seems to
still be required on the function definitions by another part of the
code so these have been left in place.

The functionParams method has to filter out JVM bridge methods to ensure
the correct version of the apply() method (with type parameter
information) is captured.  Function objects only have one defined method
named apply() so taking the head of the list should always be safe.
Not sure if the code generation is still being used as the functions in
ScalaDsl seem to have diverged slightly from what this script would
generate in it's current form.

Updating it to reflect the new logic anyway in case it's still required.

Pushing this as a separate commit to allow cherry picking.
@aslakhellesoy aslakhellesoy merged commit c6ca457 into cucumber:master Mar 16, 2014
@lock
Copy link

lock bot commented Oct 25, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants