If you deprecate createObject() then there is no way for people to write portable, cross-engine code unless they use a feature that is deprecated in one of the engines. That basically says you are “deprecating portability”.
Deprecation says “don’t use this - it’s a bad way to write code”.
Deprecation says “change your code to use this other construct”. A construct that is not portable.
I’m sorry, but that’s just not an acceptable situation to put library and framework authors in.
Since the fork, the tone of this mailing list has become more and more like Open BlueDragon: “we (the language developers) don’t like features A, B, and C so we’re introducing non-portable, incompatible features X, Y, and Z and telling people to use those”.
The Lucee fork effectively killed Railo. That’s fair enough, it was your code to decide what to do with. There are still 2,000 folks on the Railo mailing list and virtually zero activity — 32 posts in April so far compared to normal monthly traffic of 400-500 posts. But there are only just over 500 people on this mailing list. So you haven’t migrated people to Lucee, you’ve just cut the community to a quarter of its size. That’s… terrible. For comparison, there are still over 700 people on the OpenBD mailing list despite “no one” using it.
Your documentation around Lucee 5 has been appalling. Almost every single new feature failed to work the way the documentation said and some features still aren’t documented. Now you’ve implemented objectNew() after telling us you’d implement loadComponent() and the documentation is still wrong. How are we supposed to know what to test when you can’t tell us?
At World Singles, I migrated our DEV setup from Railo to Lucee 4.5, at launch, with plans to migrate QA and production soon after. Now that looks like a dead end and we’d need, instead, to migrate to Lucee 5 which is not a drop in replacement (indeed, the documentation for the 4.5 → 5 upgrade is minimal at best and poorly written so I have no confidence in even attempting to script that upgrade). The lack of a roadmap and the lack of any clear communication around the project at all (except for some of Andrew Dixon’s work) is extremely disappointing. It really doesn’t inspire confidence.
This latest kerfuffle over createObject() has been the final nail in the coffin for me.
I closed out our Railo to Lucee migration ticket as “Will Not Fix” and I closed out a couple of other tickets that concerned Lucee 5, OSGi and changing with infrastructure as “Will Not Fix” as well.
At this point, I can’t envisage moving our servers to Lucee unless LAS seriously gets its act together — and right now I couldn’t recommend Lucee to anyone else either, in good conscience.
I hope you turn the project around — and soon — and maybe it’ll become something worth considering in the future but everything I’ve seen here over the last couple of months has further convinced me that World Singles’ decision to move away from CFML was the right thing to do, and now we’ll just accelerate that…
Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/
“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Apr 18, 2015, at 5:47 PM, Michael Offner <@Michael_Offner> wrote:
CreateObject is not touced at all, it is only deprecated (what only has a small influence on the documentation)
