Deprecate Java-specific types (biginteger, bigdecimal, byte, short, long, double)

[aslakhellesoy]

Is your feature request related to a problem? Please describe.

While working on #43 it struck me that all the parameter types that are java-specific (biginteger, bigdecimal, byte, short, long, double) don't need an explicit parameter type:

An {int} parameter can be transformed to any of the following classes:

• java.lang.Byte
• java.lang.Short
• java.lang.Integer
• java.lang.Long
• java.math.BigInteger

A {float} parameter can be transformed to any of the following classes:

• java.lang.Float
• java.lang.Doublet
• java.math.BigDecimal

Deciding what class to transform to would first use the class from the corresponding method parameter's Java type. If the Java type isn't available (e.g. for dynamically typed languages), the appropriate type would be chosen based on the string value - we'd try to fit it into the "biggest" type. E.g. "127" becomes java.lang.Byte, "128" becomes java.lang.Short etc.

A similar algorithm could be used for float.

The main reason I want to do this is to solve the "different parameter types for different platforms" problem described in #43, but with a cleaner (IMO) solution.

Another reason I want to do this is to avoid having different parameter types for different platforms, which makes it harder to implement cross-platform tools (such as the Cucumber Language Server).

Describe the solution you'd like

The gist of the solution is described above, but I'd also like this to be backwards compatible. Using any of the deprecated types will print a warning, encouraging users to switch to {int} or {float}. Implementation-wise, the deprecated types would just be aliases for the {int} or {float} types.

Describe alternatives you've considered
#43 is an alternative I have considered.

Additional context
Add any other context or screenshots about the feature request here.

[mpkorstanje]

Might be better to parse to big int and big decimal and then down grade or throw a conversation exception if it doesn't fit. That way the expected type can be described.

[mpkorstanje]

Instead of deprecation I'd consider straight up removal. Cucumber JVM can add them back as part of a graceful deprecation.

It will be easier to handle tbe deprecation warning in Cucumber JVM because it has logging facilities.

It's also easier to handle tbe deprecation there because Cucumber JVM controls it's life cycle. If we do it here then we won't be able to upgrade cucumber expressions in cucumber JVM until it goes to the next major.

[mpkorstanje]

For the tooling it will be trickier will be dealing with Javas localized number parsing. Different languages use different symbols for thousands and decimals. This is build into Javas number parsing and changes the regular expression used.

https://github.com/cucumber/cucumber-expressions/blob/main/java/src/main/java/io/cucumber/cucumberexpressions/ParameterTypeRegistry.java#L63

[mpkorstanje]

Maybe an easier solution would be to make the Java specific types work in the other languages too but always provide the int/float equivalent?

[aslakhellesoy]

For the tooling it will be trickier will be dealing with Javas localized number parsing. Different languages use different symbols for thousands and decimals. This is build into Javas number parsing and changes the regular expression used.

https://github.com/cucumber/cucumber-expressions/blob/main/java/src/main/java/io/cucumber/cucumberexpressions/ParameterTypeRegistry.java#L63

Yes, I'm aware of that. JavaScript's Intl has similar locale-specific number parsing, but it behaves slightly differently from Java's. For example 123456,789 in Norwegian is formatted as 123.456,789 on Java and 123 456,789 on JavaScript (uses a space as thousand-separator).

This makes it tricky to have cross-platform tooling, but I think that's a separate problem from deprecating the java-specific types. We can deal with that in a different issue.

[aslakhellesoy]

Maybe an easier solution would be to make the Java specific types work in the other languages too but always provide the int/float equivalent?

That's the approach I started with in #42. It's certainly easier to implement, but it feels like a bit of a hack. From a user's perspective I think it would be nicer if we had fewer parameter types and handle the conversion transparently for the user.

But I'm not sure the added complexity is worth it...

[aslakhellesoy]

As I was working on #42, I discovered that Ruby actually has a BigDecimal class.

Since Ruby is a dynamically typed language, it would be impossible to convert e.g. "123.456" into a BigDecimal with what I have proposed in this issue.

So I think it's probably best to go down the route of adding all the Java parameter types to all the implementations and call it a day.

Agree? Shall I close this?

[mpkorstanje]

Yeah. This is one of them horses.