http://coldfusion.com logo
#lucee
Title
# lucee
a

Adam Cameron

05/01/2022, 5:37 PM
Here's some Lucee weirdness:
Copy code
s = "something"

writeDump([
    "s" = s,
    "s.equals(s)" = s.equals(s),
    "s.equals(s) == true" = s.equals(s) == true,
    "s.equals(s) === true" = s.equals(s) === true, // <------------ FALSE ON LUCEE
    "s === s" = s === s,
    "(s === s) === true" = (s === s) === true,
    "(s.equals(s) && true) === true" = (s.equals(s) && true) === true,
    "type of CFML boolean" = returnsTrue().getClass().getName(), // Lucee: java.lang.Boolean; CF: coldfusion.runtime.CFBoolean
    "type of Java boolean" = s.equals(s).getClass().getName()
])

function returnsTrue() {
    return true
}
(https://trycf.com/gist/d433815998890e7129e15c82806ca78a/lucee5?theme=monokai) All works as one would expect on CF. I cannae work out what Lucee is up to.
a

Adam Cameron

05/02/2022, 2:05 PM
Ben's article? No. Brad's comment made me slap my head and go "oh fuck; of course. I already knew that Lucee sucked in this specific way!" Clarification: https://trycf.com/gist/98143d867a55faa560ae329192d255f1/lucee5?theme=monokai
Copy code
system=createObject("java", "java.lang.System")    
    
s = "there can be only one"

e = s.equals(s)

t = true

writeDump([
    "e" = e, // true
    "t" = t, // true
    "==" = e == t, // true
    "===" = e === t, // false (FUCK SAKE, LUCEE)
    "e hashcode" = system.identityHashCode(e), // one thing
    "t hashcode" = system.identityHashCode(t) // a different thing
])
Cheers for the memory jog. Oh and ping @bdw429s for yet another demonstration of how Lucee's implementation of
===
is a waste of time. Not that you needed another one.
👍 1
Semi-related Java example:
Copy code
class TestIdentiyEquality {

	public static void main(String[] args) {
		Boolean b1 = new Boolean(true); // deprecated approach to getting a Boolean
		Boolean b2 = new Boolean(true);

		System.out.println(String.format("via constructor, using equals: %b", b1.equals(b2))); // true 
		System.out.println(String.format("via constructor, using ==: %b", b1 == b2)); // false

		Boolean b3 = Boolean.parseBoolean("true");
		Boolean b4 = Boolean.valueOf("true");

		System.out.println(String.format("via parseBoolean/valueOf, using equals: %b", b3.equals(b4))); // true 
		System.out.println(String.format("via parseBoolean/valueOf, using ==: %b", b3 == b4)); // true
	}

}
s

steveduke

05/02/2022, 4:56 PM
Thanks for bringing this up @Adam Cameron. I would not assume (I did not assume) '===' was an identity operator. Given how closely cfscript writes like javascript I'm surprised they went with this.
👍 1
a

Adam Cameron

05/02/2022, 4:58 PM
This is what one gets sometimes with dedicated Java developers designing CFML: it's hard to separate-out what makes sense in one making sense in the other (and I do not mean this as a slight at all). The Adobe CF Team have the same problem sometimes.
4 Views