tracker issue : CF-3752316

select a category, or use search below
(searches all categories and all time range)

listChangeDelims() member function missing

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 04/29/2014

Components: Language

Versions: 11.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 6

Listed in the version Issues Fixed doc
There is a changeDelims() method, but not a listChangeDelims()

So ain't really fixed properly.


----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3752316

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:



listMap(), listEach(), listFilter() etc also have not been fixed. I'm not gonna bother reporting other ones missing, but pls make sure to do a thorough job this time round ;-) -- Adam
Comment by External U.
12458 | April 30, 2014 07:18:39 AM GMT
delimiter is meaningful only for list and therefore there is no ambiguity on this. That is the reason the list methods dont need any separate qualification. list.changeDelims() is better than list.listChangeDelims() Same is the case for map, each and filter methods. They apply only for collection and I don't see any ambiguity there.
Comment by Rupesh K.
12459 | April 30, 2014 07:47:32 AM GMT
Please just do what you agreed to do in: Also see: Please listen to your community... we tend to have a better handle on how CFML works and is used and what gotchas there will be than you guys do. You have not made an informed / sensible decision here. -- Adam
Comment by External U.
12460 | April 30, 2014 07:51:19 AM GMT
Of course we listen to you and the community and we agreed to change the method names to avoid the confusion. A big thanks to you for the feedback. We changed all the methods except the ones where there is absolutely no ambiguity. Now if you are saying that each, map, reduce, filter methods need to be prefixed with "list", I need to be convinced. Please explain.
Comment by Rupesh K.
12461 | April 30, 2014 07:58:43 AM GMT
It's entirely reasonable that there *could* be a string-based function which performs char-by-char operations; for example Ruby will do this: "abcd".each_char{|c| puts c } And this could be extended to all the iteration functions. In fact they'd be quite handy. Equally, you are just cloudying the language, and making it less predictable. If all the list functions had list member functions with *the same name*, that's just one thing to remember. As it stands, we now have to remember the vagaries of you decided to implement it. I could possibly agree with listChangeDelims() being obvious it's a list-specific function *if its case was taken in isolation*, but if one steps back and looks at the bigger picture, it's a poor decision to single out functions that we second guess are / are not ambiguous. Havnig the list prefix (as per the standard functions) unambiguously states "this function treats the string as a list". It might be tautological in places, but overall the uniformity wins out, I think. Go read the blog article and all the comments. -- Adam
Comment by External U.
12462 | April 30, 2014 08:11:12 AM GMT
I too, would prefer the consistency of the names rather than trying to guess. Case and point-- CFML doesn't have a changeDelims() function-- it has a ListChangeDelims() function. The same argument could have been made there, but it wasn't. Let's just keep everything the same-- ESPECIALLY since strings could contain other data in them that we may want member functions for later. What about this: myArray = "[ 1, 2, 3 ]".SerializeJSON(); Just because something isn't a string, doesn't mean it can only be treated as a list. Let's label the list member functions as such.
Vote by External U.
12478 | April 30, 2014 02:14:42 PM GMT
A programmer friendly language, which we all thought we had with cfml, requires the language to be intuitive... member functions are more intuitive, but only if you can remember the names of them... and if you have to remember some have prefixes and some don't, you lose that. Please make them CONSISTENT... which is what EVERYONE has been saying all along.
Vote by External U.
12479 | April 30, 2014 03:47:23 PM GMT
Wait, didn't you guys just make str[i] work? So strings look like arrays? Just like so many other languages that treat strings as arrays which are collections and therefore perfect candidates for each(), map(), filter(), and reduce(). Or maybe it was Railo that very sensibly made str[i] work? Either way, a string is a perfectly valid collection and every language I can think of that supports iterator functions lets you apply them to a string. Therefore any CFML functions that expect to treat strings as lists - a conceit peculiar to CFML and a spectacularly bad piece of language design in the first place - need to have a prefix of "list", which was exactly what the community asked you to do! But, no, you Java developers think you know better than all those folks who use CFML every day, don't you???
Comment by External U.
12463 | May 01, 2014 01:43:13 AM GMT
This is a stupid inconsistency based entirely on your lack of understanding of language design and the fact you are not CFML developers. Stop trying to second guess people who actually know and use CFML every day!
Vote by External U.
12480 | May 01, 2014 01:44:58 AM GMT
Not continuing with the switched 'list' prefixed naming conventions here breaks continuity and can only be for the worse. PLEASE FIX THIS ADOBE!
Vote by External U.
12481 | May 01, 2014 02:47:08 AM GMT
This is yet another example of how short-sighted Adobe is being when it comes to making a language easy to use and consistent with itself. We already have had to deal with list functions that sometimes have the list as the first parameter and sometimes the second which is incredibly annoying and makes introducing bugs in the code FAR too easy. This is just another example of how not making related functions consistent makes life harder for developers and the language more prone to bugs than it needs to be.
Comment by External U.
12464 | May 01, 2014 01:17:27 PM GMT
A stupid and unnecessary inconsistency that just makes it harder on developers and forces us to have to spend time looking up which functions start with "list" and which don't.
Vote by External U.
12482 | May 01, 2014 01:18:37 PM GMT
Just noting that the list member functions not prefixed w/ 'list' are: changeDelims(), each(), filter(), map(), reduce(), sort(), valueCount() and valueCountNoCase(). Additionally, myList.filter() hasn't been implemented yet. (#CF-3755346)
Comment by External U.
12465 | May 06, 2014 12:20:22 AM GMT
+1 - I agree w/ everyone else here. Regardless of ambiguity, * list member functions should be prefixed w/ 'list' for consistency (and for future support of char-by-char operations on all strings). Developers shouldn't have to remember which list functions do begin w/ 'list' and which ones don't. The community voted for * list member functions to begin w/ 'list' and still does.
Vote by External U.
12483 | May 06, 2014 12:21:25 AM GMT
all right. marking it as ToFix and we will include it in the first update. In case one has used these list methods, he/she would need to change the code.
Comment by Rupesh K.
12466 | May 06, 2014 12:43:24 AM GMT
Thank you Rupesh!
Comment by External U.
12467 | May 06, 2014 12:53:05 AM GMT
That is very cool Rupesh (and understandable about changing the code), thank you! -Aaron
Comment by External U.
12468 | May 06, 2014 01:41:17 AM GMT
Following List member function will be prefixed with 'List' : changeDelims(), filter(), sort(), valueCount() and valueCountNoCase() (Comment added from ex-user id:nawani)
Comment by Adobe D.
12469 | September 02, 2014 05:56:18 AM GMT
Anuj: Rupesh had agreed to prefix all the list functions with "list". Please read the comments below, and the various linked docs (and read them thoroughly). Bear in mind also that Rupesh's assertion that constructs like list.listChangeDelims() is tautological is not correct, because there is no such thing as a "list": it's a string. So in reality it's vital to have the list prefix on ALL LIST FUNCTIONS, because the construct is actually this string.listChangeDelims(). So you need the prefix to make clear you're treating the string as a list. Otherwise it seems like a string function, and there is no indication what changeDelims() means in the context of a string. You are relying on ppl already knowing that it's "special", which is poor design. Plus it makes sense to prefix all list functions the same way. It makes NO SENSE to prefix most of them, but not all of them. Bottom line, please just finish the job properly so we can all move on. -- Adam
Comment by External U.
12470 | September 02, 2014 06:18:30 AM GMT
tested listfilter(),map(),reduce(). logged a bug for listfilter():CF-3817316
Comment by Suchika S.
12471 | September 03, 2014 05:32:17 AM GMT
Will make the change to map, reduce and each to have them prefixed with list
Comment by Vamseekrishna N.
12472 | September 03, 2014 10:25:37 PM GMT
I have to admit - after all the back and forth on this ticket - I don't trust you to do this job properly, and am concerned you'll do an incomplete job. From the list functions listed here - - can you state what action you are taking / has already been taking / etc, so we can check if you've missed anything or done the wrong thing anywhere. Cheers.
Comment by External U.
12473 | September 04, 2014 02:18:08 AM GMT
map() changed to listMap() and reduce to listReduce(). tested and it works fine.
Comment by Suchika S.
12474 | September 09, 2014 01:04:30 AM GMT
I've verified all list member functions have been prefixed w/ 'list' in CF11 Update 3. myList.changeDelims() => myList.listChangeDelims() myList.each() => myList.listEach() => myList.listMap() myList.reduce() => myList.listReduce() myList.sort() => myList.listSort() myList.valueCount() => myList.listValueCount() myList.valueCountNoCase() => myList.listValueCountNoCase() the missing myList.listFilter() was introduced Awesome. Thanks!, -Aaron
Comment by External U.
12475 | November 05, 2014 09:30:11 AM GMT
Excellent. Cheers for sorting this out, Adobe, and cheers for testing it, Aaron!
Comment by External U.
12476 | November 05, 2014 09:41:03 AM GMT
Hi Adam, You're very welcome! -Aaron
Comment by External U.
12477 | November 06, 2014 09:39:18 PM GMT