FYI: along this process we will also revisit all “deprecated” functionalities and change them to “avoid”, i think in most cases.
Since I was one of the strongest objectors to marking
createObject() as deprecated, I’ll point to the C++ ANSI Standard definition of “deprecated”:
Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.
In 2012, there was a proposal to refine this wording to be more explicit:
Normative for the current edition of the Standard, but been identified as a candidate for removal from future revisions of the Standard
A specific example is the
register keyword which was marked “deprecated” in C++11 and followed up in late 2014 with a proposal to remove it from C++17.
Back when the ANSI Standards Committee overhauled the standard library and deprecated all the old
.h header files in favor of the newer headers with no explicit
.h suffix, our sense was definitely that those old
.h header files would be removed from the Standard in the future (even tho’ that overturned decades of preceding C / C++ practice).
This is why I think “deprecate” should really only be used for things that are candidates for removal in the future.
I like the idea of “avoid” for something that should be discouraged so I like @micstriit’s position of changing all “deprecated” functionalities […] to “avoid”.
Call it Avoid; it’s as good a name as any – especially if it removes the semantic debate around the definition of deprecated. My point is simply having two (or more) different states that mean effectively the same thing – avoid using – is a waste of effort.
Developers will have to read the documentation in any event to determine why exactly they are avoiding that feature. The documentation can give all the detail that is actually needed to make an appropriate decision about the features ongoing use, or the alternative approach.
What are the other C++ states beyond “Normal” and “Deprecate”?
I’m coming to this party a bit late, but how about the redefine deprecated
to the ANSI understanding, as it seems to be the most common
understanding. Then add the 4th as “superseded”, instead of “avoid”. The
reason is keeping a positive spin on things. Devs (at least this one
will look at a status of avoid and think, “why have a language feature at
all if I’m supposed to avoid it?” However if I see superseded, I’m getting
excited to learn a new approach to solving my problem.
As I said in another post, I agree that developers would want to look up why something is Avoid or Deprecated. And the documentation needs to cater for this accordingly.
Regardless if there is a misinterpretation of Java’s Deprecated or not — I don’t think it is because what was quoted back then in the respective thread was a piece of documentation of how to use the documentation attribute “@deprecated” in Java and THAT was misinterpreted imho, but anyway —having a 4th status of Avoid that clearly makes a non-endorsed way of coding is valuable and after considering the options, I think it should be added.
Yes, I’d be very happy to change my proposal to use “Superseded” instead of “Avoid” - that makes perfect sense.
@agentK while I’m happy to be convinced, I’m not seeing the value here. Perhaps you could offer 5 examples in the current code base where the term “superseded” (nee Avoid) would be used to good effect, over the existing term “Deprecated”.
The only thing that springs to mind for me is the
createObject() controversy. In the presence of a separate dialect like Lucee Language, surely this would have resolved itself? That is,
createObject() in the CFML dialect would remain until such time as Adobe decided to deprecate, if ever. And
createObject() would not exist in the Lucee Language dialect at all, having been superseded.
@seancorfield am genuinely interested here in the status assigned by other languages.
If something is discontinued, the language team has flagged the desire to remove that feature at some time. The period a deprecated element remains in a language is a factor of how deeply entrenched it is in the community and the impact its likely to have once removed. So while the desire is there, the pragmatic reality is it may never be removed – only the documentation could explain the expected timeframe to developers.
I thought your position on
createObject() was that “deprecate” clearly telegraphs the desire to remove the function, even if the underlying intent was to retain the function due to compatibility concerns. In retrospect, I’d agree you were right. The addition of a 4th status appears to be drifting away from the clarity of that argument.
Is it really a good idea to flag to developers that a particular feature has been superseded but it’s ok to continue using said feature. Wouldn’t this just lead to the build up of cruft we see in CFML today?
In the standards world, there are generally just the two states: “normal” and “deprecated”. Deprecated features generally do get removed from future standards, sometimes in the next revision, sometimes in the revision following. There isn’t always a “better way” added to replace it. In the
register example I gave, compilers just stopped needing to be given that hint.
In the Java world, deprecated is more for library authors to mark an API as “to be avoided” / “superseded” with a better way – a different signature of the same function is most common. Whether a deprecated feature is removed later is up to the library author. Java’s evolution is glacial so standard library functions marked deprecated tend to stay around for a very long time.
In the Clojure world, deprecated is used more in the standards sense, by both the language designers and library authors. Deprecated things do tend to go away (eventually).
Coming back to CFML / Lucee: “deprecating”
createObject() in CFML is a bit silly since it’s just not going away until Adobe decide it is (which is likely never given their obsession with backward compatibility). For Lucee, you can just go right ahead and remove it – for the Lucee language, you can simply require folks do it a different way.
I don’t really see any point in “avoid” / “superseded” to be honest – that was more a suggestion to avoid the charged meaning of “deprecate” in a context where LAS do not intend to remove a feature (because compatibility).
@micstriit seems to want a way to label features as “undesirable” but without the intent to remove. If that’s the case, then “deprecate” is the wrong term, in my opinion.
Each of them is currently “deprecated” but will never be removed of Lucee’s CFML engine due to it waiting for Adobe do do anything with them and Adobe won’t because they rather die than breaking their big US govt client’s crappy CF 4.0 codebases (ParameterExists).
They should all be superseded/avoid instead of deprecated unless Lucee’s CFML implementation will deprecate them in 1-2 versions.
Regardless, such a flag describes the reality. The word “avoid” also made it very clear that it’s NOT ok to continue using said feature and that there are better ways.
What would we gain from changing the status of those functions from “deprecated” to something else?
Clarity. Please read the initial post and the scenario description:
My opinion on @agentK’s post would agree with @justincarter I think: I see no point in labeling those features as anything other than “deprecated” since that’s what Allaire / Macromedia / Adobe has decided (regardless of whether they ever will remove them – given they’ve floated ACF12 might not be entirely backward compatible, I guess we can hope?).
I think the Lucee language can “do the right thing” here and simply remove things that folks would like to see “deprecated” / “avoided” in CFML. After all, if we all agree something is “bad” and that the Lucee language provides a “better” way, why bother supporting the old, bad way at all? That’s why I think labeling features of the Lucee language as “avoid” (or whatever) is a bit pointless: just omit them.
Not sure if that answers your question?
I don’t know if it provides any clarifty for CFML functions that are marked “deprecated” by Adobe?
For createObject, let’s just drop it from Lucee Lang
I believe this was done in the context of CFML dialect still being the principal language of Lucee. Since that time LAS come around to a more concerted view that Lucee Language will have to be the principal way forward; trying to evolve CFML without Adobe is just too hard a task.
With that in mind I imagine @micstriit would have no issue reverting
createObject() to normal and hiding the suite of
createComponent() et al functions that were to supercede it in CFML. And then having
createObject() struck from Lucee Language entirely.
But I think you are making my argument for me.
The point of Lucee Language is to give us the opportunity to evolve our own CFML implementation. That said, the CFML dialect should strive for compatibility with Adobe’s official CFML offering. Lucee should not be making any determination about the CFML dialect that is not in line with Adobe CFML. If Adobe has these listed as “deprecated” then we should also list them as “deprecated”, otherwise they should be normal.
We should never be recommending an unofficial alternative in the CFML dialect. We should only be providing features on the CFML dialect in line with the features available in Adobe CFML and with the syntax dictated by Adobe CFML.
I’d certainly be more than happy with that course of action
Just to make things very clear: This proposal was talking about CFML the way forward, not about LuceeLang.
Sure, that’s another way of solving it.
However with @modius saying that:
the consequence would be that the current CFML implementation in Lucee 4.5 would have to be trimmed back in Lucee 5 to exactly what ACF offers in their CFML implementation, right?
I did not read @modius’s post that way. I read his post as saying “We should not be labeling things in the CFML dialect any differently to how Adobe labels them in its implementation.”
Since it was posted on the LuceeLang forum, I guess I took it as relating to LuceeLang so thank you for that clarification.
I suspect we’d all do better to focus on LuceeLang and what we want in that, rather than worry about doing anything to the CFML dialect (beyond adding new features to stay compatible with Adobe ColdFusion’s new features if warranted).
OK I read this whole thread again and now I am more confused then before. Could someone summarize these points into what we plan on doing?