Wednesday 30 April 2014

ColdFusion 11: if Adobe haven't quite sapped yer will to live yet...

... could you do me a quick favour?

A while back I raised this ticket with Adobe: 'List member functions should all be prefixed with "list"'; it's kinda self explanatory, but the gist is they'd implemented list member functions (good), but changed the names of the member functions to no-longer match their headless function counterparts. So the member function version of listAppend() was just append(); listEach() was just each().

I figured this was of dubious merit as it muddied what was a list-oriented member function and what was simply a string-oriented one (.append() could just as easily do a string-append as opposed to a list-append), and this notion got a lot of support: "Survey results: lists in CFML, and the naming of list member functions".

Credit where it's due, Adobe marked it to fix, and indeed "fixed" it before release of ColdFusion 11. So now we have myList.listAppend(), myList.listFind(), etc. But we still have myList.changeDelims(), myList.each() and a few others haven't got their list prefixes.

I duly raised another bug to cover this, yesterday: "listChangeDelims() member function missing".

Today Rupesh simply closed this ticket as "Closed/Withdrawn/NotABug", offering this insight:
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.
Honestly? Sigh.

Anyway, I pointed out that there was a fair amount of community support behind this, and we kinda know what we're talking about compared to him, but I get this back:
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.
I feel like saying "Oh FFS, just do what yer fuckin' told, will you?", but that's probably not going to work.

Another thing that occurs to me now is that it's just really poor form to undertake to "fix" a bug, and then do something different. If there was some disagreement as to the approach, the time to bring it up would be before developing it, not afterwards. Now these dud functions are in the wild. Which is going to make it harder to convince Adobe to sort them out. Next time, Rupesh, come back on the original ticket and go "hey, we figured this... [explanation]... what do you guys think? Is that OK?" That'd be a) cool; b) save us all some time. Actually mostly Adobe's time.

So the favour... can you pls go and put your oar in on this one, if you feel so inclined? Cheers. Thanks to Brad for already commenting.