Should "." be handled as a number?

language proposals
1

placeholder for a discussion about [LDEV-4480] - Lucee

2

Nooo, please… That is a string and nothing else. Why should it be interpreted as a number? what is the reason that string could be interpreted as a number? Would look like some sort of automagic regex to me :smiley:

3 Likes
3

yeah i tend to agree, i think it was related to this

image

image
image321Ă—521 6.92 KB

bonus lucee 6 regression! java.lang.NumberFormatException on line 10 (tho trycf is on 6.0.0.455, latest is 6.0.0.523)

that said

image
image1174Ă—706 52.1 KB

I’ll note trycf is running 5.4.2.17, I wish they would label the Lucee version like they do with ACF and also have a 5.3 version available… Lucee 5 is pretty vague

(adapted from @AdamCameron’s example on slack)

4

No. Because it’s not a number.

CF:

writeOutput(isNumeric(".")) // no

JS:

parseFloat(".")
NaN

Java:

// control
s = "1"
f = createObject("java", "java.lang.Float").parseFloat(s)
writeDump([s,f]) // 1, 1
    
s = "."

// is it a float?
try {
    f = createObject("java", "java.lang.Float").parseFloat(s)
} catch (any e) {
    writeDump([
        e.type, // java.lang.NumberFormatException
        e.message, // For input string: "."
        e. //
    ])
}


// is it a Double?
try {
    d = createObject("java", "java.lang.Double").parseDouble(s)
} catch (any e) {
    writeDump([
        e.type, // java.lang.NumberFormatException
        e.message, // For input string: "."
        e. //
    ])
}

Also if one just checks what a decimal point is (googles “decimal point”, and read for a few seconds): it’s a separator. In some (but not all, as Micha ought to know!) number-representation systems it’s the separator between the whole number part and the decimal part of the number. It is not - itself - a number. In a lot of places - including Switzerland! - a comma is used here.

There should have been no guesswork here: before the initial code was implemented, the behaviour ought to have been checked. Shit happens and sometimes people forget - that’s cool - but then when an error is found the fix for the error should not be put to the gen. pop.: this is not an opinion-based / majority-based thing. Y’alls shoulda just checked (like I have, above).

8 Likes
5

test cases added and current behaviour documented between branches in ticket

2 Likes
6

Should “.” be handled as a number?

No. Doing so will lead to all sorts of complications.

A quick example:

<cfscript>
dotString=".";
zeroString="0";

NumberFromDotConcatenation= 1 & dotString & "2";
NumberFromZeroConcatenation= 1 & zeroString & "2";

writeOutput( "NumberFromDotConcatenation = " & NumberFromDotConcatenation);
writeOutput("<p>");
writeOutput( "NumberFromZeroConcatenation = " & NumberFromZeroConcatenation);
</cfscript>

Output:
image

My system:
Lucee 5.4.1.8
Windows 10 Professional

2 Likes
7

I agree it should be treated as a string. I ran into this issue on Friday with some code that was supposed to be checking if a character was a dot:

x = "0";
if (x == ".") {
    writeOutput("x is a dot");
}

Took me a while to figure out why tests were failing on 5.4 :slight_smile:

4 Likes
8

Agree that “.” should be treated as a string. This bug in Lucee 5.4.3.2 caused an error with our email validation which has a check that the email cannot begin with a “.”. Emails that begin with “0” (zero) are failing that check which forced us to rollback to our previous version (5.3.10.97).

1 Like