StructDelete or StructIsEmpty broken in CF8?

Report · Sep 02, 2009

I have found what appears to be a CF8 bug?

My code:

In my case the URL has one key called "SN". I delete it using StructDelete function.

I then immediately test it for emptiness...using StructIsEmpty, but it displays No. Yet, a dump of the URL struct shows it is.

What gives?????

Here's the output I get:

struct
SN	/products/fpga/ecp/index.cfm

RC: YES
StructIsEmpty: NO

struct

Report · Sep 02, 2009

I get the same thing in CF8 & CF9.

I would guess that it's structIsEmpty() that's bung.

It seems specific to the URL scope... if one alters your code slightly to use a normal struct, everything works as one would expect.

Do you wanna raise a bug with Adobe?

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#

--

Adam

Report · Sep 02, 2009

It seems specific to the URL scope... if one alters your
code slightly to use a normal struct, everything works as
one would expect.

Do you wanna raise a bug with Adobe?

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#

--
Adam

Check the bug database. It should already be there. (It also applies to the form scope.)

Report · Sep 02, 2009

From: cfcoder2
In my case the URL has one key called "SN". I delete it
using StructDelete function.
I then immediately test it for emptiness...using
StructIsEmpty, but it displays No. Yet, a dump of the URL
struct shows it is.
What gives?????

Technically, URL and FORM are not structures. The issue appears to be related to that fact. In the mean time, if you want the same behavior as with standard structures, use duplicate(). Then perform your operations on the copy.

http://cfsearching.blogspot.com/2009/06/that-which-we-call-structure-by-any.html

Report · Sep 03, 2009

Your blog post is very interesting, and makes a good amount of sense. But the fact remains that if CF exposes the underlying data structure as a struct, and struct functions "work" on it, then the results should conform to the expectations one would have based on the documentation of the relevant struct functions.

--

Adam

Report · Sep 03, 2009

But the fact remains that if CF exposes the underlying data structure as a struct, and struct functions "work" on it, then the results should conform to the expectations one would have based on the documentation of the relevant struct functions.
--
Adam

Yes, I had mixed feelings on that when I wrote the entry. It seemed like a bug. But for all I knew there was a good reason those scopes behaved the way they did. But on reflection, I agree with you. Since it behaves "like" a structure in almost every other way, to break with the user expectations here is counter intutive.

Edit: But obviously there is no way to change the current behavior. Hence the suggestion of using duplicate();

Report · Sep 04, 2009

Technically, URL and FORM are not structures.

Could you please expand? I think they are.

Report · Sep 04, 2009

BKBK wrote:
Technically, URL and FORM are not structures.
Could you please expand? I think they are.

I think we all agree they are very similar, but technically they are not instances of the same class returned by structNew(). The classes used to represent URL and FORM behave differently when you check the size() method. That method is probably what is used to determine whether the objects are empty or not. (See also the explanation in the link above)

<cfset parent = structure.getClass()>
structNew() object:<hr>
<cfoutput>
<cfloop condition="IsDefined('parent')">
#parent.getName()#<br>
<cfset parent = parent.getSuperClass()>
</cfloop>
</cfoutput>
<br>

<cfset parent = form.getClass()>
<cfoutput>
FORM object:<hr>
<cfloop condition="IsDefined('parent')">
#parent.getName()#<br>
<cfset parent = parent.getSuperClass()>
</cfloop>
</cfoutput>

Report · Sep 05, 2009

...technically they[Form and URL] are not instances of the same class returned by structNew(). The classes used to represent URL and FORM behave differently when you check the size() method. That method is probably what is used to determine whether the objects are empty or not. (See also the explanation in the link above)

The statement, "technically they[Form and URL] are not instances of the same class returned by structNew()" is correct. However, the statement, "Technically, URL and FORM are not structures." isn't. For Form and URL are, technically, Coldfusion structures.

Arguments based on inheritance relationships in Java make sense in Java. Coldfusion is a custom implementation of Java. The majority of Coldfusion functionality are wrappers for a diversity of underlying Java objects. It is therefore not always possible to carry such arguments over to Coldfusion.

The concept of structure is one such argument. It is a concept that makes sense in Coldfusion, but not necessarily in Java. To illustrate, the object structNew() belongs to the inheritance tree

coldfusion.runtime.Struct
    => coldfusion.util.FastHashtable
        => coldfusion.util.CaseInsensitiveMap
            => java.lang.Object

This doesn't imply that whatever Coldfusion technically calls a structure must belong to that tree. A Coldfusion structure is an umbrella term for a wide range of objects, some of whose inheritance trees differ from that of structNew(). In other words, there are Coldfusion objects, like Form and URL, whose inheritance trees are different from that of structnew(), but which are technically Coldfusion structures all the same.

Otherwise, we'll be saying on the one hand that an object X isn't technically a structure. Whereas, on the other hand, isStruct(X) evaluates to True.

The main point Cfcoder2 has raised is consistency. If isStruct(Form) is true and Form contains no data, then structIsEmpty(Form) must be true. The same goes for URL.

Report · Sep 05, 2009

BKBK wrote:
...technically they[Form and URL] are not instances of the same class returned by structNew(). The classes used to represent URL and FORM behave differently when you check the size() method. That method is probably what is used to determine whether the objects are empty or not. (See also the explanation in the link above)
The statement, "technically they[Form and URL] are not instances of the same class returned by structNew()" is correct. However, the statement, "Technically, URL and FORM are not structures." isn't. For Form and URL are, technically, Coldfusion structures.

I hear what you are saying, but I think you are missing the point of the entry. You are talking general concept (which I think we have all agreed on already). By that logic, I myself often refer to a variety of objects as "structures" even though they may not be structures in the strictest sense. But what I am discussing is the concrete implementation ie classes not "structures" in the general sense. The concrete classes are the reason why the two objects exibit different behavior. So in that sense, FORMScope and URLScope are not structures (ie the class returned by structNew()). That is the point of the entry: why there is a difference in behavior. I think everyone has already agreed that most of us consider those scopes to be "structures" in the general sense and because of that we expected a different outcome from IsStructEmpty and StructCount. Otherwise, this thread never would have been posted 😉

Report · Sep 03, 2009

Thanks for the comments and responses and for confirming my suspicions.

Now if we can get Adobe to fix this anomoly in their code. To me I agree that the behavior should conform to that of a struct for URL and Form. However they seem to act partially like a "read only" struct. Maybe there are ramifications to making it conform as a true struct but AT A MINIMUM, they should clearly document the behavior so that developers can quit wasting time over finding this bug out over and probably over again.

Listening, Adobe???

Report · Sep 03, 2009

cfcoder2 wrote:

Listening, Adobe???

If you feel that strongly, make certain it IS in the bug database. If it is, cast your vote for that bug and add your comments. If it is not there, enter it as a new bug.

Report · Sep 03, 2009

I am willing to submit this but the link provided in this thread is for CF9 beta.

If there is a place to submit CF8 bugs I'll do it. I tried the CF9 bug base and it does not list CF8 except for CF8.0.1 J which I assume is for Japan?

Report · Sep 03, 2009

cfcoder2 wrote:
I am willing to submit this but the link provided in this thread is for CF9 beta.

Adam said he confirmed the behavior exists in the CF9 beta. So it is appropriate IMO. Search first to see if it is already entered ..

If there is a place to submit CF8 bugs I'll do it.

I do not think there was a public one prior to the CF9 beta. Someone correct me if I am wrong on that.

Report · Sep 03, 2009

OK then what beta is it? The form asks which one. I have no contact with CF9 at this point and likely won't till post release.

I'll need the build number and OS, too.

Report · Sep 03, 2009

Edit: Okay. I saw you entered it after responding.

I do not which beta version they are up to now. Adam might know. But I can also confirm the behavior on the version I am using:

9,0,0,241018

Report · Sep 03, 2009

OK I went ahead and filled out the bug report for CF9 Beta 1.

I left build data out but stated there that it fails in CF8 (implying it's been around for a while)

I did search to see if the bug had been previously reported and could not find any reports. I searched on StructDelete, StructIsEmpty and URL.

Report · Sep 04, 2009

More info on the issue

<cfset structure = structNew()>
<cfset customStruct = structNew()>
<cfoutput>
<cfloop list="form,url,customStruct" index="structType">
<cfswitch expression="#structType#">
    <cfcase value="customStruct">
        <cfset structure = customStruct>
    </cfcase>
    <cfcase value="form">
        <cfset structure = form>
    </cfcase>
    <cfcase value="url">
        <cfset structure = url>
    </cfcase>
</cfswitch>
<h3>#structType#</h3>
<p>
#structType# not yet populated: <cfdump var="#structure#">
</p>
<cfset structure.myVar ="1">
<p>
#structType# populated: <cfdump var="#structure#">
</p>
<p>
<cfset isDeleted = structdelete(structure,"myVar","true")>
After implementing structdelete, structIsempty(#structType#):<cfdump var="#structisempty(structure)#"><br>
<p>
Dump of #structType# after implementing structdelete: <cfdump var="#structure#">
<hr align="left" width="50%">
</p>
</cfloop>
</cfoutput>

Report · Sep 04, 2009

This is more good proof of the bug.

What is very interesting to note is that the dumped structs for Form and URL at the end of the code shows an empty struct but the label doesn't indicate that it is like the custom struct does... "struct" vs. "struct [empty]". It's acting like there are hidden elements in there.

Thanks for the code post, BKBK!

Report · Sep 04, 2009

cfcoder2 wrote:
This is more good proof of the bug.

How so? It seems like the same issue to me. ie Assigning the variable just changes the variable reference to point to the FORM or URL objects. So it is essentially as if you were still using the FORM/URL objects.

<h3>#structType#</h3>
<cfoutput>#structure.getClass().name#<br></cfoutput>

Report · Sep 05, 2009

How so?

Cfcoder2 says how. That is, how it is "more proof".

Form and url display "struct". Whereas the custom struct displays "struct[Empty]".