http://coldfusion.com logo
#lucee
Title
# lucee
a

Adam Cameron

02/18/2022, 12:07 PM
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).
s

sknowlton

02/18/2022, 12:47 PM
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?'
Maybe not good but less bad than automatically doing whatever Adobe does or doesn't do
a

Adam Cameron

02/18/2022, 1:03 PM
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.
w

websolete

02/18/2022, 1:52 PM
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?
1
m

Matt Jones

02/18/2022, 2:21 PM
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.
s

sknowlton

02/18/2022, 6:38 PM
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'
w

websolete

02/18/2022, 6:51 PM
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
b

bdw429s

02/18/2022, 7:43 PM
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.
@websolete So to answer your questions
unclear what the motivation for deprecating something as uncontroversial as valueList is
The answer is more simple and boring them you may imagine. And is solely that the functionality of
valueList()
overlapped with that of
QueryColumnData()
so it was "necessary" (per Micha) to ensure one of the two was deprecated.
also, weren't we supposed to have the 'lucee language' by now? is that not on the books anymore?
LuceeLang was put "on the shelf" indefinitely quite a few years ago when LAS realized they didn't have near the resources to keep up with normal Lucee CFML, let alone an entire new language with • no docs • no frameworks • no users • no formal language spec • no public mindshare and until they came into a few million dollars of lottery money, it just wasn't going to be feasible.
Personally, I never saw anything wrong with having two ways to accomplish the same thing and I really wish Lucee had never felt the need to slap a deprecation label on anything just for the sake of a "_their can only be one_" sort of attitude. I don't mind having a "recommended" or "suggested" way to do it, but this has caused far too much agony n people thinking it's a cardinal sin to use
encodeforXXX()
or whatever (and I've had clients refuse to allow me to use it!) just because Micha flipped a coin once 8 years ago and decided he like
esapiEncode()
instead as his personal preference.
w

websolete

02/18/2022, 7:52 PM
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.
b

bdw429s

02/18/2022, 7:52 PM
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
w

websolete

02/18/2022, 7:54 PM
still, i think the term 'deprecated' isn't being used appropriately here. 'preferred' or 'favored' or 'sanctioned' or something seems better.
1
maybe 'archaic'
for the outdated syntax
b

bdw429s

02/18/2022, 7:57 PM
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!"
w

websolete

02/18/2022, 7:57 PM
on cfdocs the word used is 'Discouraged'
b

bdw429s

02/18/2022, 7:57 PM
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.
w

websolete

02/18/2022, 7:58 PM
on a positive note, setVariable() is still supported on lucee 5. so,
setVariable("hypocrisy","for the win");
is valid.
💪 1
a

Adam Cameron

02/18/2022, 8:43 PM
Not helped by ppl's understanding of "deprecated" is usually wrong anyhow.
Personally, I never saw anything wrong with having two ways to accomplish the same thing and I really wish Lucee had never felt the need to slap a deprecation label on anything just for the sake of a "_their can only be one_" sort of attitude
Agreed. Also: not his decision. Micha (et al) really need to get that these choices are not even theirs. It's Adobe's language. They are doing everyone a disservice (and being self-indulgent) by thinking otherwise. If you wanna copy someone else's work then by all means do it. But do that.
because Micha felt it improper to ever have two ways of doing the same thing. i.e., two BIFS that accomplish the same task.
Following this logic, the BIF is
valueList
, and
queryColumnData
should never have been created in the first place. Whether or not it's a better implementation (it is) is neither here nor there, following his own premise
queryColumnData
should never have been created. And "deprecating" the one that is common to both "dialects" in favour of his own special one is simply misapplied hubris.
(which kinda implies there's appropriately-applied hubris. 🤔 )
2 Views