Classification of "features we don't think are a good way of coding anymore"

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 :slight_smile:
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.

5 Likes

Good call.


Adam

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.

1 Like

@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?

2 Likes

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.

1 Like

Sure:

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:

I’m a little confused here @justincarter as you’ve quoted @agentK but Discourse shows this as a response to my post?

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 :wink:

1 Like

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 :smile:

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

2 Likes

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?

1 Like

Um, nothing.

Here’s my understanding of this thread:

@agentK intended this to be about the CFML dialect, not the Lucee dialect, and as @modius said (and several folks seemed to agree), we should leave stuff in the CFML dialect documented as it is to match Adobe ColdFusion.

For the Lucee language, stuff can just be omitted if we think it shouldn’t be used (and Lucee has a better way). If we do want LuceeLang to retain a CFML feature but want to signal to developers to use a different feature instead, for whatever reason, @micstriit indicated he’s happy to label such features as “avoid” rather than “deprecated”.

(an agreement to “do nothing” is still a useful outcome from a discussion)

1 Like

“nowServer” was a function mainly used by Railo in the admin and I think was never well adapted in the community, it was never the indent that this function is used in the users code base. i Think we could savely assume nobody is using this function anymore, so I think the status “deprecate” makes a lot of sense for this function even we have the status “avoid” as well. we should consider to set the status to “hidden” for this function for Lucee 5.

Even if we agree that something is bad, does not mean that my code base is not full of it and i (or my client) has not the money/time to rewite that code what would make a next release a showstopper. there is a big difference between removing something and having all this states. What we really need is the possibility of a setting in the admin that allows to throw a exception if you use “deprecated/avoided/hidden” functionality, so you can check very fast if you use flagged features and of course that should be always enabled in the development enviroment.