http://coldfusion.com logo
Join Slack
Powered by
Seems like a bug in all Lucee versions (and Railo)...
# lucee
b
Seems like a bug in all Lucee versions (and Railo) available on trycf.com) (good luck searching existing issues for the word "format". I can't even find the function in Lucee or ACF docs any more) https://trycf.com/gist/94923a9b2e3420fa0c1c6eeaf83bf7c4/lucee5?theme=monokai Basically, in Lucee, string.format( string, [1,2,3,4] ) converts those numeric token values to decimals (1.0, 2.0, 3.0, 4.0, ...) where all ACF versions on trycf.com display them as they should be.
To get the same results as ACF in Lucee, I have to change those numbers to strings in the array. 
string.format( string, ["1","2","3","4"] )
a
format
is a 
java.lang.String
method, not a CFML function. And your issue is nowt to do with 
format
anyhow. It's how each engine internally stores integerish values: https://trycf.com/gist/f5e8659a99eddd46a3afd5a2b0471549/acf2021?theme=monokai
Copy code
n = 123;
writeDump([
    class = n.getClass().getName(),
    toString = n.toString()
])
Copy code
Lucee:
CLASS java.lang.Double
TOSTRING 123.0
Copy code
CF:
CLASS java.lang.Integer (String before CF2018)
TOSTRING 123
👍 1
So, based on that, when you call a method on the Java object (like 
toString
) then you'll be getting the Java result. If you used the CFML function 
toString
instead, yer problem goes away. Not a bug, just a misunderstanding of the code in question.
b
Maybe the toString() example is a misunderstanding but, overall, the basic examples act differently in Lucee than in ACF. Since the Lucee mantra is "backwards compatibility", then how is this not a bug?
a
There is no specification for CFML: Adobe does not mandate how variable values ought to be stored internally. Therefore if Lucee wants to store the literal 
123
as a Double rather than an Integer, then... so be it. That's the start and the finish of anything to do with CFML in this. Provided Lucee's CFML implementation then exposes that value uniformly according to how CFML is documented to behave, then there is no bug. You are calling a Java method on the variable, and Java doesn't care about CFML, so when you say 
myDouble.toString()
, you will get however Java is specified to handle that. And it won't be the same as how Java's spec mandates how 
myInteger.toString()
behaves. Nothing to see here: move along. This is all as expected. When you then call the Java method 
String.format
(it is not a CFML method), then the rules of Java apply: again, CFML has nothing to do with it.
Your code is kinda "breaking the fourth wall" (tenuous metaphor, I know), as yer using Java not CFML in that example.
Now. Ideally should Lucee just stick to copying CF so this stuff never crops up? Well: yes. If CF stores 
123
as a 
java.lang.Integer
, then so should Lucee. Sure. All Lucee's types should be the same as CF's. All of them. Even when CF decides to change from storing them as `java.lang.String`s, Lucee should have already been using `java.lang.String`s, and then gone "oh FFS CF you changed it!", and then they should have changed that too. However. Like I said there's no CFML spec, and really I can see how Lucee would focus their efforts on the "surface" of CFML, not the inner workings. There's enough of that they haven't quite nailed yet before worrying about the inner workings that automatically come with a "know what you're doing" before ppl ought to go use them. Advice for the once bitten: when calling Java methods on an object in CFML... make sure you check what the type of the object is first. And also understand the difference between CFML member functions and Java methods. And... have units tests on everything so when porting across platforms you know when stuff fails before hand.
Since the Lucee mantra is "backwards compatibility", then how is this not a bug?
Oh and also be aware that they only apply this when it's convenient. They are more than happy to do whatever the hell they like that's different from CF's implementation under the guise of "well we felt like doing it different because we're clevererer than Adobe". Debatable. Especially if one looks at the bigger picture.
👎 1
e
It's open source, you don't have to like it, in fact, you are encouraged to fork it and f**k it till it works for you. 🙂 Now AFC you start decompiling their jars and they send in the cops and lawyers should you try to share your findings.
👍 1
z
cfml is a dynamic language, java is typed, ACF has moved i think to follow more of Lucee's approach of using underlying types, think about how lucee has been able to correctly serialize to json for much longer, it's due to this design decision
👍 2
b
If you feel Lucee is doing it "right" in this case, then all's well... I suppose. I saw a difference in code results between the two and wanted to point it out... not push the start button on the snarky old man machine.
a
I don't think there's any need to be like that. I am constrained in how I can explain stuff a bit... I've got to second guess the audience a bit, and I was trying to reword the-same-thing-again-but-differently as it didn't seem to land the first time. No judgement. I did the best I could, sinking more time into it for you than I now think I ought to have bothered with. And, again... the bits that you were commenting on ... 
format
and 
toString
... aren't Lucee / CFML. This is a bit like me pointing at some broken code in front of me (which is PHP today, and it's def currently broken FFS!), and say "bloody bug in Python". It's fine that you went "oh this is different, I didn't expect that". Absolutely right & on point, and indeed a bit curious on initial inspection. It's the bit about it being a Lucee bug that was off target. Which is what I was trying to explain. And look how well that's turned out. I think I will move on now. I have that bloody bug in python to fix, after all ;-)
Open in Slack
PreviousNext
Powered by