tracker issue : CF-3752316

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.

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.

Please just do what you agreed to do in: https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3735413 Also see: http://cfmlblog.adamcameron.me/2014/04/survey-results-lists-in-cfml-and-naming.html 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

+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.

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.

Thank you Rupesh!

Comment by External U.

That is very cool Rupesh (and understandable about changing the code), thank you! -Aaron

Comment by External U.

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.

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.

tested listfilter(),map(),reduce(). logged a bug for listfilter():CF-3817316

Comment by Suchika S.

Will make the change to map, reduce and each to have them prefixed with list

Comment by Vamseekrishna N.

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 - https://wikidocs.adobe.com/wiki/display/coldfusionen/List+functions - 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.

map() changed to listMap() and reduce to listReduce(). tested and it works fine.

Comment by Suchika S.

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.map() => 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.

Excellent. Cheers for sorting this out, Adobe, and cheers for testing it, Aaron!

Comment by External U.

Hi Adam, You're very welcome! -Aaron

Comment by External U.