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

[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.