Should I open a lucce JIRA ? I would expect a query to return strings or numbers , not the java object that it does when a column is named "url" I'm porting legacy CF11 to lucee , one application has an Oracle query that SELECTs a column "url" , in the CF11 result set "url" type is a string. Later in the code, we interpolate the url string. In Lucee, the "url" type is a lucee.runtime.type.scope.URLImpl. When we try to interpolate it, an exception is thrown to the effect that you can't interoplate a complex struct CODE:

<cfquery name="url_as_object" datasource="admin_console">
        SELECT url FROM content WHERE ROWNUM <= 1
</cfquery>
<cfset my_str="a string">
<cfloop query="url_as_object">
<cfoutput>
<pre>
        expected data for url:     #getMetadata(my_str)#
        actual meta data for url: #getMetadata(url)#
</pre>
</cfoutput>
</cfloop>

OUTPUT:

expected data for url:     class java.lang.String
	actual meta data for url: class lucee.runtime.type.scope.URLImpl

OS: ubuntu 22.04n Java Version: OpenJDK Runtime Environment (build 11.0.21+9-post-Ubuntu-0ubuntu122.04) Tomcat Version: 9.0.58-1ubuntu0.1 Lucee Version: 5.4.4.38

URL

is a scope, so also using it as an unqualified column reference in a query loop is less than ideal code to start with. And am not at all surprised that when you reference

url

that Lucee goes "that'll be the URL scope, right? Because... like... that's most likely what people will expect". So I think you should not raise a ticket in Jira, you should make yer code clearer. Maybe the documentation for how names are resolved to values could stand some improvement too, to take in the context where a name is the same as another name Lucee already uses.

Does it make a difference whether it’s a cfloop vs a cfoutput query because in that instance an unqualified variable name is meant to first look up against the query but as you said using a scope name as a column name this certainly isn’t ideal and if you raised a bug I doubt would get fixed

Even if using it as the column name, simply referencing it as

url_as_object.url

would solve the problem. @alexpixl8 are you sure that it should resolve to the unqualified query column first? That would mean it would completely shadow the URL scope, which is less than idea. I think in the case of scope names (and just scope names, not "variables in scopes), it should resolve the scope first and foremost. Like it is. But whichever case it "should be", I think the userland code should not try to shadow the scope. It's unclear code, and - as demonstrated - the behaviour is not necessarily "predictable". Best to avoid code like this.

Yeah defo best to avoid surprised it works on acf

(I have to admit I missed the "this works as described on CF11" bit). In that case... yeah, OK, whilst I reckon CF's behaviour is subpar, and one ought never write code like this, but... so be it. CF compat bug.

This is defo one of thise places Lucee broke compat with ACF on purpose. Lucee will always resolve a variable reference beginning with a scope name as the scope, ignoring any variables of the same name. While it makes for less ambiguous code, I assume Lucee is also able to optimize the compilation of such code.

I’d be happy with it going on a known issues register same as arrays by value vs reference

Yep provided it is not just some hidden docs page somewhere one needs to know where to look to find the info. But linked to from the page about scopes, the page about variables, the page about cfoutput & cfloop, etc. People should not need to look for this stuff, they should find it (if you see the subtle difference there).

Agreed. I know this because I had the discussion once years ago with Micha and he explained it. It needs to be on a doc page somewhere for sure.

Isn't it an option in the Lucee Admin to determine how scopes are ordered? Or am I hallucinating that? (sorry, on mobile so I can't verify)

There is a modern scope behavior which simplifies the searched scopes and changes the default assignment scope if I recall. it has nothing at all to do with the question at hand however, which is unscoped access to a vatriable whose name matches that of a known CF scope.

Gotcha, thanks.