valueList

is marked as deprecated on Lucee (ref: https://docs.lucee.org/reference/functions/valuelist.html). Is it really for Lucee to be deprecating something in CFML, given it's up to Adobe what is and is not deprecated in their language? What's the perceived gain in marking it thus, other than making devs writing cross-platform from going "oh FFS". Which to me is not a gain. (yes, I have read https://docs.lucee.org/reference/deprecated.html. That is not what I am asking).

Given the attitude Adobe has toward the language (Lucee and Commandbox don't exist, we won't even tell our own customers much about how we make decisions regarding the language) ... I don't really see an alternative answer to this question besides 'if they ain't gonna, who is?'

Slightly off topic for my particular question, but to your point: I think Lucee's deviation from Adobe's reference implementation of CFML has done more harm than good, overall. I think once it became clear that Railo's "improvements" from CF's CFML implementation were coming up again and again as cross-compat concerns, Lucee should have adopted a policy of "mirror CF", and poss even moved any of their changed behaviours inherited from Railo out into extensions. For one thing, I don't think Lucee's language design skills are any less bad than Adobe's. So not sure it's playing to their strengths to pretend otherwise. Two different sets of engineers making subpar design decisions helps no-one.

personally i don't mind 'innovation' or deprecating some cf constructs by lucee, but the prudent thing to do it seems to me would be to offer those back in in some type of compatibility/polyfill extension so that they can be removed from lucee core but reintroduced if need be. unclear what the motivation for deprecating something as uncontroversial as valueList is, but an extension as described above would make it less problematic. also, weren't we supposed to have the 'lucee language' by now? is that not on the books anymore?

I definitely agree that their use of deprecated is a problem here. My first and the most annoying example to me of similar was around the encoding function battle that fortunately landed on encodeForXxx() on both acf and lucee. IMO, "Discouraged in Lucee, Prefer Xxx() instead" wouldn't be bad, because it would better convey what I believe to be the intent.

well there's the strategic question of: what's the right general attitude to have; and then there's the tactical, 'did we, having that attitude, make the right move.' I can't/won't argue that Lucee's particular decisions were for the best (though some of them may well have been) but I don't think that would change my view that an attempt which the rest of us can sit here and poke holes in is still better then 'welp, Adobe said six words about this on a ticket in 2013, so that's the language'

in this particular case, valueList, the queryColumnData method they want you to use IS superior in that it separates the query.column attribute into two distinct arguments, which is an improvement to be sure. and, if they had planned to leave valueList/Array in there but push people to use the other, then that's fine really. maybe too much is being read into the term deprecated as matt noted above

Generally speaking, the impetus for most deprecation in Lucee is because Micha felt it improper to ever have two ways of doing the same thing. i.e., two BIFS that accomplish the same task. Anywhere this existed, he felt the need to ensure one of the two methods was "deprecated" to help lead people to one of the two solutions he felt was superior.

agreed. seems hard to truly defend, given you still have multiple ways to execute a query, for example, which i guess is ok? or arraynew(1) vs [], or the various ways of looping complex objects. seems not very worthwhile to take a hard position on something when there are tons of artifacts in the language that remain untouched.

I know for sure Micha/lucee never intended their deprecation warnings to be any more than a friendly nudge at the fork in the road to a possibly "better" option. Most of the issues were created by people taking it as a gospel truth and freaking out over it. That was never the intention

still, i think the term 'deprecated' isn't being used appropriately here. 'preferred' or 'favored' or 'sanctioned' or something seems better.

Right, and this is the conversation that's been had many times. The last time it was had with Micha, his take was, "Well, we'll tell people what we mean when we use the word and then that will clear all the confusion!"

on cfdocs the word used is 'Discouraged'

Though, this has obviously not been the case. There is an understandable hard knee-jerk reaction people have to seeing something they use marked as deprecated and a little note 3 paragraphs down in the docs doesn't help them.

on a positive note, setVariable() is still supported on lucee 5. so,

setVariable("hypocrisy","for the win");

is valid.

Not helped by ppl's understanding of "deprecated" is usually wrong anyhow.