Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
1 of 1

Possible regression with equality checks between Lucees 5 & 6

Fixed

Description

Repro:

//C.cfc component {}
<!--- test.cfm ---> <cfscript> o1 = new C() o2 = o1 try { writeOutput(o1 === o2) } catch (any e) { writeDUmp([ type = e.type, message = e.message, detail = e.detail ]) } try { writeOutput(o1 == o2) } catch (any e) { writeDUmp([ type = e.type, message = e.message, detail = e.detail ]) } </cfscript>

Lucee 5:

true Can't cast Component [C] to String

Lucee 6:

Can't cast Component [C] to String Can't cast Component [C] to String

 

This change in behaviour was not listed in https://luceeserver.atlassian.net/browse/LDEV-1282 , but I suspect it’s the cause.

By comparison, CF errors on both with:

Complex object types cannot be converted to simple values. Complex object types cannot be converted to simple values.

So if it was the intent to line-up with CF here, all good, but you need to make that clear in the release notes ticket detail.

However DASH-1282 is about === and this regression is about == so I’m not convinced it was intentional? Or perhaps there’s another ticket I can’t find that relates to this?

Environment

None

Details

Assignee

Reporter

Priority

Labels

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Parent

Sprint

Created 12 June 2023 at 10:32
Updated 16 June 2023 at 15:57
Resolved 16 June 2023 at 15:21

Activity

Show:

Adam Cameron16 June 2023 at 15:57

Yeah my point was whilst DASH-1282 is on that list, NOWHERE ON THAT TICKET did it mention you changed the behaviour of ==. it was all about ===. Just cos you changed it as part of that ticket, doesn’t mean we know that. So if you change something other than what exactly is on a ticket, you really ought to update the ticket to reflect that.

One should either do only what is on the ticket, or - if the scope changes (and fair enough) - also update the scope of the ticket to make that clear, eg “as part of this I have also changed how == works” (and that would need to go in the title as well, given it’s non-trivial). For all anyone else knew, the behaviour I reported could have been a bug that you unintentionally introduced.

NB: has sorted-out DASH-1242 now, and it’s perfect. It might be worth you checking what he has done as a benchmark for next time.

Good work on the other ticket and it’s appreciated. It’s just the comms that were wanting a bit here, but that’s also now sorted so: excellent!

Michael Offner16 June 2023 at 15:46

all tickets with a breaking change are in this epic https://luceeserver.atlassian.net/browse/LDEV-4534 including this. for the Release candidate we will communicate this of course. maybe there is already a list for this, will know.

Adam Cameron16 June 2023 at 15:31

What you have done is absolutely fine given it was by design and not just a side-effect of the work in DASH-1282.

Is it documented anywhere that you have changed the behaviour of ==? I couldn’t find anything at the time, but that doesn’t mean much as == is not great to search for

Cheers for the feedback / clarification!

Michael Offner16 June 2023 at 15:21

if you disagree we can discuss it and reopen the ticket.

Michael Offner16 June 2023 at 15:14

we completely changed how this operator work, now it is compatible with the ACF behaviour including this case.

So a breaking change by design.

Flag notifications