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

Which is exactly the point:

My emphasis. Geoff was saying Lucee should not, e.g., recommend javaProxy() over createObject() in the CFML dialect. It’s fine to make such recommendations in LuceeLang.

And I also read his comments with an implicit “Going forward…” at the beginning.

2 Likes

Maybe @modius could elaborate what exactly he means. As said further up, I read his statement in a very similar way to @adam_cameron’s interpretation.

Summary of my position:

  • do nothing; what we have now is fine, do not add another state
  • improve documentation; always a worthy goal
  • follow Adobe’s lead with respect to deprecation within the CFML dialect
  • follow our own lead with respect to deprecation in Lucee Language; if and when the need arises

This is a discussion about the merit of the addition of a state that is a synonym for Deprecated. I find it hard to fathom, what value there is in removing that specific context from my words.

1 Like

Have to admit that I have not read most of the thread but could reading this document on the wiki have saved all this?

https://bitbucket.org/lucee/lucee/wiki/Statuses%20of%20functionality

I’d probably start by reading the post that you extracted the comment from. That’d probably help. Lemme know if that leaves anything unclear.


Adam

Indeed. It doesn’t really seem as if you got as far as the first posting in the thread.


Adam