Lucee 5 beta: Follow-up to a direct question about createObject()

G'day:
This is still going 'round the houses: "Lucee 5 beta: a direct question about createObject()". Here's my latest follow-up, just FYI.

OK, I think I have enough of a handle on this to report back now. Micha has Michasplained everything now I think.

Is this a fair summary (and opinion-based but basically neutrally-toned comment from me):

I asserted that instead of the delivered solution to this, createObject("path.to.component", initArgs) should work.

• Micha mentioned in passing I think that - taken in isolation - syntactically it would work. I think he still fell short of stating clearly one way or the other though.

• No-one else seemed to have more than a passing opinion specifically on this, one way or the other.

Micha asserted that createObject()'s non-init()-calling behaviour is fundamentally wrong

• This is because in other languages, there is no concept of a dual-state object: un-init()-ed and init()-ed.

• However there is over ten years of precedent and code set in CFML which contradicts this. We are only discussing CFML here. Other language's approaches to things should be considered for new functionality, and considered in changes / bugfixes, but they are not signficant when it comes to trying to redefine well-established CFML behaviour. As ppl (not usually me) are wont to say: CFML is not Java.

• he gave some legit examples where existing behaviour can cause unexpected or undesirable results.

• this position presupposes the CFC dev in question is unaware of how CFCs work in CFML, and that that is not something easily solved.

• Micha makes the claim that the CFC developer should not have to cater to both un-init()-ed and init()-ed behaviour. Whilst possibly true (but presupposes Micha's first point above, which is by no means broadly accepted), this solution in no way addresses this, because CFCs still need to work with createObject() used exactly as it functions now. So this cannot be used as a justification for these changes.

• I personally don't think Micha has met his burden here. CFML objects simply have never behaved the way Micha wants them to, and if Micha was serious about this being as fundamental problem as he claims, the fix would be more comprehensive than deprecating a function.

• it also presupposes that people have a fundamental issue with simply calling init() manually such that very core CFML functionality should be deprecated, and new not-cross-compatible functions added.

• In short, and in my opinion, this consideration needs to be taken off the table because the solution doesn't / can't actually address it.

Micha asserted that having to use new "#path.to.component#"() for dynamic CFC paths is "ugly"

• and this is a fundamental-enough that very core CFML functionality should be deprecated, and new not-cross-compatible functions added?

• this is entirely subjective, and should not have been a consideration in this work. And, for one thing, I don't agree: I like that I can do that in CFML! Not that my opinion is gold, but it demonstrates Micha's not fundamentally right about this.

• In my opinion this consideration should never have been on the table in the first place.

A fundamental part of Micha's solution was the deprecation of createObject(), and a move to three other functions, each dealing with CFML objects, Java objects and web service... objects (there you go Andrew, happy now? ;-)

• It was observed that there are different ideas of what deprecation is. Each side of the discussion thusfar have pulled out definitions that have suited them, as if that contradicts or somehow invalidates the other side's position. This is poor logic, and a poor research technique. What it actually demonstrates is that there are various perfectly legitimate "definitions" ("usages", perhaps?) of that term, and I think in the real world one needs to accept that it's going to be how the community member receives that information more than how Lucee want to transmit it.

• Alex (via Twitter) maintained Micha did not mean "deprecated", but merely meant "unfavoured". I personally think he did meant deprecated. And the definition of it which means "and marked for eventual removal". However I don't think this has been made terribly clear either. It'd be a lot better if Micha explained his position on stuff like this rather than other people (inc; myself) trying to second-guess it, TBH. And I mean what his position was at the time he designed this solution, not wherever it's subsequently ended up.

• In my opinion Lucee simply can't deprecate this function.

If Micha meant deprecation as "end of support, and flagged for eventual removal", this has impact on framework / library authors

• it's been suggested that those authors should not be thinking that, and they should continue to use createObject() as-is if that makes them feel more comfortable, because - realistically - createObject() is not going anywhere, and will continue to work as per now

• obviously this message will be extended to everyone else too.

• In my opinion this invalidates the new "solution" almost entirely, because it doesn't achieve what it sets out to do, because it can't replace the existing functionality.

If Micha didn't mean deprecation in the sense that people might interpret it (or doesn't mean deprecation any more)

• then what's happened is simply that Lucee has added three new functions which have partial or whole overlap with well-established existing functions.

• I my opinion this strikes me as poor language design.

There is still disagreement over the naming of the new functions

• Andrew's raised some nomenclature concerns.

• I will articulate my own opinion separately (TL;DR: they're not right yet).

It's been pointed out that compatibility-breaking changes like this should be targeted for .lucee, not CFML

• this is what it's supposed to be for, after all

• I don't think anyone would complain if createObject() was simply fixed in .lucee

In short:

• we're stuck with the behaviour of createObject() as it stands now.

• Accordingly it cannot be deprecated.

• Accordingly the need for new functions (at least in the context of CFC-based objects) is voided.

• so you might as well just fix it the way I suggested in the first place, for CFML

• and properly fix createObject() in .lucee

Note: I did not form the list of points above simply to arrive at my "in short" conclusions. I did not add that until I was doing my proofread, but I think it stands up, logically?

I am sure I missed some important stuff in this. I am more sure I filtered out an awful lot of really unimportant stuff ;-)

Thoughts?

--
Adam