Dunno - do you actually agree with everything I suggested ? G-)
On 28/11/2019 20:45, Jochen Theodorou wrote:
On 28.11.19 00:44, MG wrote:
Um - no, I said:
m1 : STC error - giving a floating point literal when an integer is
expected could point towards an error, and there is no inconvenience i
On 28.11.19 00:44, MG wrote:
Um - no, I said:
m1 : STC error - giving a floating point literal when an integer is
expected could point towards an error, and there is no inconvenience in
writing 1 instead of 1.0 .
so both should not work.
I did misread, sorry. Well, then matters should be cle
Um - no, I said:
m1 : STC error - giving a floating point literal when an integer is
expected could point towards an error, and there is no inconvenience in
writing 1 instead of 1.0 .
so both should not work.
On 26/11/2019 08:27, Jochen Theodorou wrote:
On 25.11.19 14:21, MG wrote:
Are we
On 25.11.19 14:21, MG wrote:
Are we discussing different things here ? I understood the question to
be about number literals ("GROOVY-8488: STC: floating-point _literals_
no longer accepted as args to method with double parameter"), not
variables of number type.
I am only arguing for literals to
I don't see a consistency problem if this would go, but besides that,
just ask yourself:
1. How many times do I have a situation like that ?
2. How often do I not want to control the exact format of the resulting
string representation of the number in case ?
3. In that remaining cases, how in
Are we discussing different things here ? I understood the question to
be about number literals ("GROOVY-8488: STC: floating-point _literals_
no longer accepted as args to method with double parameter"), not
variables of number type.
I am only arguing for literals to be conveniently groovy, not
Hello everyone,
That is an interesting example (actually I was not aware that groovy does that)
Am 24.11.2019 um 01:28 schrieb Simon Sadedin :
> Chiming in late here, but the only one I would passionately argue about is
> the string <=> numeric conversions. The implicit conversions to / from St
Chiming in late here, but the only one I would passionately argue about is
the string <=> numeric conversions. The implicit conversions to / from
String already in Groovy have been responsible for a large proportion of
the impactful bugs that have come out of my complex groovy code. For
example, th
On 23.11.19 03:08, MG wrote:
On 22/11/2019 17:51, Jochen Theodorou wrote:
So strictly spoken none of the calls to m1 and m2 should be supported
here. But this is a problem for the user, as the user is not used to
write 1.0d instead. And it will make a lot of programs cumbersome. But
it would be
On 22/11/2019 17:51, Jochen Theodorou wrote:
So strictly spoken none of the calls to m1 and m2 should be supported
here. But this is a problem for the user, as the user is not used to
write 1.0d instead. And it will make a lot of programs cumbersome. But
it would be more correct.
I know you are
On 21.11.19 17:05, Milles, Eric (TR Tech, Content & Ops) wrote:
[...]
*Do we expect number literals (such as BigDecimal, BigInteger or even
just Double) to be acceptable arguments to methods that accept "int",
"double" or "String"? Is there some limited set of automatic
conversions that STC shou
Hi Eric,
I am using STC a lot i n my framework, and have run into problems with
"too much strictness". My take would be:
m1 : STC error - giving a floating point literal when an integer is
expected could point towards an error, and there is no inconvenience in
writing 1 instead of 1.0 .
m2:
12 matches
Mail list logo
