Provide table row values as converted parameters

I've pushed a patch into a branch on my github fork for this.
https://github.com/dgodfrey/jbehave-core/tree/nested-conversion

The reason for having different parameter converters for different raw types is to distinguish the parameter List<String> from List<Number> (as you can see in the accept(Type) method.
We can add a parameter converter for lists that delegates to the element parameter converter (which would be specified when instantiating the converter), so it can reused for different types of element converters, but I don't see the benefit of some of the elements in the patch. In particular, changing the ParameterConverters from class to interface and changing the converter method signature would break backward compat.

Creating a ListConverter which takes a delegate ParameterConverter in the constructor still entails boilerplate and also means I can't then (easily) use a @AsParameterConverter method as the delegate. The ListConverter I pushed solves all of this and works for List<T> where T can be any Class, by delegating back to ParametersConverters to do the actual conversion.

I only renamed ParametersConverters -> DefaultParametersConverters and extracted the interface, so I could mock the interface when testing some of the ParameterConverters. Just made the testing a bit easier.

I also pushed a follow-up patch that adds a ParameterTable, which wraps an ExamplesTable, providing access to converting the cells into other types, again using the existing ParametersConverters. I tried just injecting an instance of ParametersConverters using Guice, but it didn't include any of my @AsParameterConverter conversions, only the default ones.

The rename would break backward compat, and if primarily motivated by testing reasons, it is not a good idea.

Let's focus on the functionality requirement and try to satisfy it with current design. I see no problem in adding other parameter converters but would not want to break backward compat.

So what is your primary use case: using Lists of parameters converted via methods annotated with @AsParameterConverter?

I've pushed my extensions to the initial patch for this onto
https://github.com/dgodfrey/jbehave-core/tree/jbehave_398

Hi Dan, I've pull the latest change from branch. I'm really not too convinced about the rename of Row -> Record. Also, can you please clarify the usecase for the chaining implementation and the defaults?

Yes, an example story in trader would be most welcome!

I'm starting to get the use case, but a concrete example would be useful.

Dan, I've renamed Record -> Parameters (below) as it seems a logic name to describe a collection of parameters. I've removed the need to subclass to a specific converting implementation. The map implementation has been removed as it is a corner case of the converting implementation. The refactoring maintained the unit test behaviour as specified by you. Do note that I've also move the Parameters classes to the steps package, as it's where most of the parameter-related logic is.

public interface Parameters {

    /**
     * Determines if the parameter of a given name is found
     * 
     * @param name the name of the parameter
     * @return A boolean, <code>true</code> if found
     */
    boolean hasValue(String name);

    /**
     * Returns the value for parameter of a given name
     * 
     * @param type the Class of type <T> to convert to
     * @param name the name of the parameter
     * @return The value of type <T>
     */
    <T> T valueAs(String name, Class<T> type);

    /**
     * Returns the value for parameter of a given name and provides a default
     * value if the name is not found
     * 
     * @param type Class of type <T> to convert to
     * @param name the name of the parameter
     * @param defaultValue the default value if the name doesn't exist.
     * @return The value of type <T>
     */
    <T> T valueAs(String name, Class<T> type, T defaultValue);

    /**
     * Returns the map of all the values as Strings
     * 
     * @return The Map of values
     */
    Map<String, String> values();

}

Updated trader example to use table with parameters defaults.

Makes sense, Parameters is a much better name.

I don't like the hierarchy reduction though, it means ChainedParameters needs to implement all of the valueAs methods, which as far as I can tell, won't ever be called anywhere. I've pushed another patch to https://github.com/dgodfrey/jbehave-core/tree/jbehave_398, that introduces another interface, RawParameters, that removes this necessity. It also removes the hasValue method completely, as it's not required any more. IMO, it's enough of a code reduction to add the tiny new interface for.

Pulled up Row interface with the "raw" values, which is implemented by ChainedRow, as suggested in the patch.