Here s some Lucee weirdness ```s = something writeDump s = s cfml #lucee

Here's some Lucee weirdness: ```s = "something" ...

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.

Jonas Eriksson

05/02/2022, 8:25 AM

⭐ 1

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

Adam Cameron

05/02/2022, 2:08 PM

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
	}

}

Adam Cameron

05/02/2022, 4:11 PM

Seemed like a reasonable topic for a blog article: https://blog.adamcameron.me/2022/05/cfml-with-lucee-true-isnt-necessarily.html

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

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

Open in Slack

Previous Next