Question regarding

cfloop

: Reading the documentation in Adobe about

index

and

item

attributes for a list is quite vague as to how these attributes work together. When only using

index

attribute (ie

index="idx"

), the list element is assigned to the

idx

variable within the loop. However, when using both

index

and

item

attributes (ie

index="idx" item="itm"

), the behavior of the

index

attribute changes by assigning the true index number of the item in the list and the

item

attribute is assigned the element, instead. Why does the behavior for the

index

attribute have to change? Is it because of backward compatibility? If a developer wants to only grab the true index number in a list, then they are forced to extraneously include the

item

attribute. Am I missing something?

I'm guessing legacy versions of CF. Certainly there's a lot of CF code out there developed for CF9 and below that use 'index' to contain the list element that would be broken if this behaviour changed.

historically index and item were mutually exclusive depending on whether you were looping a struct or something else. i've honestly never thought about having both stipulated in a single loop, and not sure why that would be a Good Thing to do that.

It's odd because we are forced to upgrade things in newer versions of ACF like the 'd' vs 'D' in date formatting or the reserved word

final

and have to check and rename all of the places within the application for this, and I understand the impact is not as great as it would be for changing a cfloop index that probably exists in every application out there, but this implementation becomes hampered and bound to previous versions and devs continue to use the attribute in backwards compatibility, even if the application is new development. It seems the best bet would be to allow backwards compatibility flag settings for these sort of backwards enhancements so that ACF coding can advance correctly. Example: If folks upgrade and have index used only, then they will see a number if they don't turn on backwards compatibility for cfloop. Moving forward, devs can better understand the true purpose instead of having to find out how things work because of poor documentation and hand-tied implementation in order to appease older versions. It leads to crazy implementations like this that make no sense.

we used to not be allowed to include index and item together, it would thow an error. you would have to provide an additional mechanism to get the extra portion. you either looped from 1 to len of the object, then drilled into the object to get the item or you looped the item and tracked the index separately

If a developer wants to only grab the true index number in a list...

If you just want the index, just use an indexed loop. It's what it's for.

<cfset letters = "a,b,c,d">
<cfloop index="i" from="1" to="#letters.listLen()#">
    <cfoutput>#i#</cfoutput>
</cfloop>

fair enough, but it's easier to understand that the

index

attribute to always be used for grabbing the index number rather than attempting to understand how

index

works in certain cases that changes the behavior of how

index

is used. Especially, when

item

is only used for the element. Let's "KISS" and keep

index

only used for the index number.

Oh, I agree that

<cfloop>

is a mess.

Right, which is why I always feel like I have to look up cfloop in order to understand how attributes work together, forget about remembering it all, especially since it changes with backwards advancement. I know I will be looking this up again down the road, because it is difficult remembering every special case in cfloop.

However the decision that in a list loop that

index

when used by itself means "the _item_" has been that way at least since CF5. There is no reason to break that - purely out of a sense of pedantry - to accommodate both

index

and

item

. The way that's been done is legit. I mean what else were they gonna call the thing with the number in it in that situation?

If a new dev sees

index

, I don't think that the dev would think that the item would be returned, but rather, the index number. Moreover, now it flip flops in behavior, which is even worse.

I had not typed in a

<cfloop>

for the best part of a decade, and seldom did even back then, but still remembered it's index for lists, item for structs, but if one uses both, then it's uniform for both lists and structs.

it is funny ain't it? Lol However, I have seen new CFML devs, fwiw. 🙂

But more seriously... there's lots of shit that a new CFML dev will encounter. That's the whole "new" bit. And TBH, I reckon after this conversation even you might remember how it works from now on?

agree with the tag bit. I definitely endorse script-based coding and prefer writing in it, however, depending on who I work for, I sometimes don't have a choice or that it is not worth the effort due to time involved to convert.

yup. I am working on a largely tag-based codebase currently. However I'm only doing maintenance coding and writing tests (the tests are all script obvs).

LOLOL - That depends on how many social events with libations are in between. 😉

[same applies to both examinee and examiner in this case]