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

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.

That would be CFML code. Which you’d keep as CFML code. And the Lucee server would run it unchanged.

We’re talking about LuceeLang not including features. There is no LuceeLang code yet. There is no backward compatibility issue here.

LuceeLang can omit CFML features without affecting CFML code. That’s kind of the whole point here isn’t it?

@seancorfield - Thanks for the summary. I agree doing nothing is a reasonable outcome. Not sure that is the case with this thread since @micstriit goes on to refer to avoid and other status.

I think this is where all of this is breaking down. Once something was discussed and most of the responsible parties were involved the expectation is that a decisions will be made. Am I wrong in my assumptions?

Given that what are the status labels being applied to CFML or / and LuceeLang?

I thought I knew what had been agreed until @micstriit chimed in :frowning:

1 Like

This is a place for discussion. We’re working on better process around decision making. But I’m pretty sure that discussion threads are not the place for that. They certainly are the place to get a feeling of consensus, thrashing things out and airing opinion - and all of that will have a big influence on the decision making process.

If you have ideas around concrete ways Lucee can move things through to clear conclusions, chime in here: http://lang.lucee.org/t/input-gathering-formalizing-process-of-lucee-language-evolvment/141

Possibly not the right place for that discussion, so I’ve started a new thread.

Back to this discussion… I can’t quite work out what you’ve been saying on the topic today Micha. It’s perhaps about time we started trying to put this topic to bed, so could you pls give us your thoughts on the actual topic at hand, which is purely one of how to document (or flag) functionality that’s deprecated.

Now it was news to me that this forum is only supposed to be about the .lucee dialect, and I was fairly certain this topic was about Lucee’s CFML features, and how to deal with cruft Lucee wanted to get rid of.

However recently I have heard these things:

  • this forum is only about .lucee, not about Lucee’s CFML implementation. Can someone from LAS (on a different thread, pls) clarify that? It’s news to me.
  • Lucee’s CFML offering is just gonna mirror Adobe’s. This was news to me, and somewhat confusing given all the new Lucee/CFML-only features added into Lucee 5. Can someone pls clarify THAT on another thread too pls?
  • these being the case, I see no reason for this conversation at all. Firstly .lucee doesn’t exist yet so it’s a bit preemptive to be thinking about deprecating stuff and how to articulate that
  • from Lucee CFML’s perspective, there’s nothing to decide really? Just follow Adobe’s lead.

Can we get a position from LAS on this topic on this thread, and perhaps we can then put it to bed? I’m not rushing it, but the more I read, the less certain I am about what the current position on it is. I think we’ve probably thrashed out everything thrashable, and just need a decision now?

Cheers


Adam

1 Like

I say have patience. Its not that big an issue and LAS aren’t going to be able to come to an “official concensus” without spending a bunch of energy on the topic (and the members of LAS might not be the best people to do that). Until we have a straightforward process in place to make these decisions, I say this issue should take a back seat (we have plenty of input to review for when the time comes).

Ok, I can live with this is a place for the discussion and not a place where the decision is made. What I am still confused about is what are the status being considered and did we come to some consensus to present to the decision makers.

Seems pointless to me if the discussion does not at least end in a consensus even if that consensus is we (the people who choose to discuss the issue) agree to disagree.

That’s kinda what I was meaning in my previous response. Dom seemed to be getting the impression I was giving them the hurry-up despite specifically saying I wasn’t.


Adam

@adam_cameron - I agree.

Since the people who chose to discuss the issue are the interested parties ending the thread with a consensus to take to the decision makers seems like a reasonable end point.

Clarification on @adam_cameron points 2 and 4 (basically the same thing: does CFML layer just mimic Adobe’s version, with differences only appearing in .lucee?) would be most welcome.

If so, it then begs the question: do current differences get walked back so that “The Lucee Way” are in .lucee files and cfc|m fles stay as ACF compatible as possible? An obvious and easy example would be arrays passed by reference (note: I am not suggesting this, just that it’s the low-hanging fruit for use as an example.)

If not, then do we start now with maintaining compatibility even where we deem ACF’s implementation to be less than ideal (or downright awful?) Or do we continue to tweak the CFML-compatibility layer (or whatever it’s called) where we deem it misses the mark in addition to “fixing” it in LuceeLang?

What’s the plan?

I’m not sure where you got that impression since Railo and Lucee have always had CFML features that ColdFusion doesn’t have. I’ve not seen any indication that Lucee plan to remove those enhancements from their CFML dialect since that would break backward compatibility with both Railo and Lucee.

What I have seen from LAS folks is an indication that future enhancements would more likely be focused on LuceeLang, rather than enhancing the CFML dialect – which seems a very reasonable position to take. I suspect some new LuceeLang features could be easily backported to the CFML dialect and that might be worth doing.

1 Like

@micstriit has gone on record several times as saying that he’s happy to break ColdFusion compatibility in places where the ColdFusion implementation is stupidly broken – and this is one of those cases that has been discussed several times over the years. The decision to do copy-on-assignment for arrays was just dumb (it’s not, technically, pass-by-value). It was made a long time ago and was kept (by Macromedia / Adobe) purely for backward compatibility with previous ColdFusion versions. Suggesting that – and other, known, documented differences in behavior between ColdFusion and Railo/Lucee – be “walked back” in the name of “compatibility” is a non-starter at this point.

1 Like

Dom seemed to be getting the impression I was giving them the hurry-up despite specifically saying I wasn’t.

Not just yourself @adam_cameron ;). We’re all understandably impatient, a symptom of a lack of well-defined and oiled process. The trouble is, its very, very hard for people to come to a consensus in an open discussion like this. Even pinning the discussion down to a single point is hard. But, my effort to clarify:

Original suggestion: Add a status of “Avoid” to the internal status flags and documentation for Lucee functions and tags to clear up the ambiguity of “Deprecated”.
Main counter argument: Just need to clarify definition of “deprecated” and expand on the reasons and alternatives for each deprecation

The discussion then got into Lucee lang vs ACF compatible CFML. Do either or both of the positions above fit into Lucee CFML, Lucee Lang or both?

I’ll stick my neck out on an official LAS position: decision to be made at first sensible opportunity by the right group of people (in an open way).

OK, I did not understand that the discussion was simple to add “avoid” (or its equivalent) to this already defined list.

deprecated
hidden
implemeted
unimplemeted

It would help if someone gave the current definition / use of these statuses in the current code base.