createObject(). Focused question...

[Adam Cameron]

G'day:

I've had several (well: a few) discussions with Micha regarding createObject(), and its future, vis-a-vis createComponent() (now loadComponent()). However I cannot see anywhere that Micha has answered one of my questions without getting distracted by other considerations. So I'll ask again.

This is the question, and the only thing I would like ppl to focus on or comment on in this thread (if that's poss):

How is it we need a new function to do CFML object instantiation (with init()), when we could just do this:

createObject("component", "path.to.component") // continues to do the same as now: creates object does NOT run init(), returns it (needed for backwards compat, but can be deprecated in favour of the third option)

createObject("java", "path.to.class") // continues to do the same as now for backwards compat reasons (this is not being contested, it needs to be the case. Can be deprecated)

createObject("path.to.component") // continues to do the same as now: creates object does NOT run init(), returns it (this is a requirement for framework developers)

createObject("path.to.component", initArgs) // creates object, DOES init() it, returns it. Solves perceived problem loadInstance() fulfils

This does not conflict with any of the syntax needed for backwards compat, continues to fulfil the requirement for delivering un-init-ed objects, and solves his particular requirement all without a new function, and stays in-keeping with current CFML usage.

Why can this not be done?

Answers will be disqualified if:

* they do not answer that one question directly

* they refer to previous discussions without just answering the question directly

* they focus on the untidiness of the inner workings of createObject() implementation which should not impact how the outward implementation of CFML effected.

* they use specious excuses like "you can't have a function that sometimes does, sometimes doesn't call init()". That is not valid: yes you can.

* they leverage a desire to deprecate createObject() entirely, because that position only comes *after* it's justified that it even *ought to be* deprecated.

* it dwells on the invalidity of returning un-init-ed objects, or how bad that is in theory without actually answering this question. Anyway: a need has been identified for this, so it's not on the table in the context of this question anyhow.

Answers will be accepted but marked down if they deal in metaphor and anecdote rather than just getting on with it and directly answering the actual question.

Cheers.

-- 

Adam

[Konstantinos Liakos]

What if the init function doesn't require any args at all? Will we have to pass null or an empty struct/array all the time?

[Adam Cameron]

On Saturday, 18 April 2015 08:21:00 UTC+1, Konstantinos Liakos wrote:

What if the init function doesn't require any args at all? Will we have to pass null or an empty struct/array all the time?

Yup, eg:

o = createObject("path.to.component", []) // or null would be another option, sure

This is less than idea, but one needs to pass some second argument there. And whilst I suggest it's "less than ideal" It's still a hell of a lot more ideal than having an alternative function loadComponent() (which is still an awful name; worse than its predecessor createComponent(), really. If not worse, than equally as bad).

Bear in mind that this entire construct is only to deal with situations where the "path.to.component" is a runtime value, and is to avoid needing to do this:

o = new "#someVarHoldingPathToComponent#"()

And the reason to avoid doing that is simply and entirely because Micha and one of his paying clients doesn't like it. That's its one use case.

For almost all other object-creation operations, one would still just use:

o = new path.to.Component()

-- 

Adam 

[Konstantinos Liakos]

I have followed all your blog posts regarding this issue. I think it is too much discussion over something so minor. The past 4 and a half years I have only faced one case where I had to use dynamic cfc naming. I think we should focus our energy to more common problems than this. Overall I don't say I favor the loadComponent function, but I have no serious problem with it being around.

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/hM3m-o9pyhg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/dc04388f-fe6b-4d24-b894-06c438a4113d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Cameron]

On Saturday, 18 April 2015 13:39:37 UTC+1, Konstantinos Liakos wrote:

I have followed all your blog posts regarding this issue. I think it is too much discussion over something so minor. The past 4 and a half years I have only faced one case where I had to use dynamic cfc naming. I think we should focus our energy to more common problems than this. Overall I don't say I favor the loadComponent function, but I have no serious problem with it being around.

Well: quite. I didn't really expect this to be anything more than a passing thing, but getting Micha to give direct answers to things seems trickier than I thought.

That said, I guess I give more consideration to the integrity of the CFML language (pardon the tautology there) than your "well I don't give a toss so why should anyone else?" sort of attitude.

-- 

Adam

[Konstantinos Liakos]

When the new Lucee version inherits all the crap from the CFML, one more won't make such a difference.

If we had something clean made from scratch, it would have meaning to give a lot of thought and consideration to each and any new feature/function added.

I know this is bad thinking, its already a mess why should I bother, but thats how I feel. The community isn't responsible for all the crap of CFML, we have just inherited them, and if we try to fix the current version we will be held responsible for all the previous versions too.

--

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/hM3m-o9pyhg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1126ccc0-ab3f-4aea-8ce1-0fef11821555%40googlegroups.com.

[Hatem Jaber]

Why didn't you guys just do something from scratch? That's what I was hoping that you would do, but it was just adding more on top of what already existed which was from what you guys did to keep up with Adobe so you can be consistent with them.

[Michael Offner]

I answered this in detail in the first comment of this blog post

http://blog.adamcameron.me/2015/04/survey-results-quick-oo-terminology.html

Short version: 

CreateObject ignores the init method, what can lead to unstable instances.

A developer should be able to make sure that instances of his components always have a proper internal state, createobject makes this job a lot more complicated.

That is btw a base rule in oo programming...

What I did wrong was that i have not deprecated createObject the day we have add the "new" operator ...

Micha

This is a implementation of the Singelton pattern. CreateObject still let me to create as many 

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/58912dc1-89b0-435b-aa5d-3244f70bfeb9%40googlegroups.com.

[Adam Cameron]

On Saturday, 18 April 2015 20:10:53 UTC+1, Micha wrote:

I answered this in detail in the first comment of this blog post

http://blog.adamcameron.me/2015/04/survey-results-quick-oo-terminology.html

This is the answer:

I answered this in detail in the first comment of this blog post

http://blog.adamcameron.me/201...

[Adam Cameron]

This doesn't stick to the rules:
* it should be on the mailing list
* it refers to previous attempts to answer, all of which were substandard, not actual answers, or just wrong-headed
* createObject() ignoring init() is *required optional functionality*, so not grounds for change. You've even accepted this (you mentioned your discussion with Luis regarding this, and Sean has also confirmed this). Plus there's over a decade's worth of CFML code which works this way. Invalid.
* plus, anyway, my solution works around that, so doubly invalid.
* no, the developer should not. Invalid.
* it might be the rule in other languages, but it's never been that way in CFML, and we are discussing a CFML situation. Invalid.

Now. Start again. Answer the question. Answer the question *as asked*. Don't invent another question and answer that one instead (which is what you've been doing).

 

[Adam Cameron]

This doesn't stick to the rules:

* it should be on the mailing list
* it refers to previous attempts to answer, all of which were substandard, not actual answers, or just wrong-headed
* createObject() ignoring init() is *required optional functionality*, so not grounds for change. You've even accepted this (you mentioned your discussion with Luis regarding this, and Sean has also confirmed this). Plus there's over a decade's worth of CFML code which works this way. Invalid.
* plus, anyway, my solution works around that, so doubly invalid.
* no, the developer should not. Invalid.
* it might be the rule in other languages, but it's never been that way in CFML, and we are discussing a CFML situation. Invalid.

Now. Start again. Answer the question. Answer the question *as asked*. Don't invent another question and answer that one instead (which is what you've been doing).

 

Micha's answer (sorry, from my blog, I'm trying to coerce him into actually replying here):

"it might be the rule in other languages, but it's never been that way in CFML"

Sorry but that is a terrible argument and I'm not speaking about other languages I'm speaking about OO.
There are 4 base rules in OO, one of them is encapsulation, the reason we have this rule is to make sure that an instance is is only use the way the developer of the class has designated.

I have made clear from beginning that we will most likely never remove createObject, we maybe will when acf will remove it, what I don't think will happen. People should simply consider not to use it anymore for be code, best use the "new" operator, in the rare case you need the dynamic approach and you don't need to be acf compatible, it will maybe a option.

"plus, anyway, my solution works around that, so doubly invalid."

How? By calling init explicitly? 

[Adam Cameron]

Micha's answer (sorry, from my blog, I'm trying to coerce him into actually replying here):

My response (now in real time, here).

Lovely. But like I said, no smoke, mirrors, deflection or other bullshit.

Answer. The. Question.

-- 

Adam 

[Michael Offner]

I did, but try me to do it with other words ;-)

if I make a init method  that is private I expect that it is not possible to create an instance from outside, if a make a init method with a required argument, I expect that it is only possible to create a instance by passing that argument. If I have a init method I expect that it is executed, always independent of the syntax I use!

Everything else is a flaw in the design of the language.

Because of that createObject("susi"); Is bad and we cannot change it, the only thing we can do is mark it as bad.

So hopefully I'm following your rules now .... ;-)

Micha

Am Samstag, 18. April 2015 schrieb Adam Cameron :

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e68914fc-5652-4c04-a16a-d66dbe03e8e5%40googlegroups.com.

[Adam Cameron]

On Saturday, 18 April 2015 22:38:24 UTC+1, Micha wrote:

I did, but try me to do it with other words ;-)

No you didn't. I'm not sure you are yet, but I'll respond anyhow. 

if I make a init method  that is private I expect that it is not possible to create an instance from outside,

CFML treatment:

createObject("Foo") // uninitialised object.

createObject("Foo", args) // exception

 

if a make a init method with a required argument, I expect that it is only possible to create a instance by passing that argument.

CFML treatment:

createObject("Foo") // uninitialised object.

createObject("Foo", argsWithoutReqd) // exception

 

If I have a init method I expect that it is executed, always independent of the syntax I use!

NO.

This is not how CFML works.

It might be how other OO languages work, and that's lovely. And CFML perhaps ought to be that way (although I think Luis and Sean will differ here), but it's not.

You are mapping your personaly OO preferences onto CFML, when unfortunately that boat has already sailed, and neither you, nor I, nor Sean, nor obalobbingbong (my Susi Sorglos) were consulted. Tough shit. This is not an option, so get it out of your head. Seriously: get it out of your head, it is not an option.

If you like, make this a rule in .lucee, and do what you like. No one gives a shit what you do there, so you can stamp yer foot and make your own OO preferences that language's particular dogma to your heart's content.

However there's over a decade's worth of CFML code out there that doesn't work this way, so yer stuck with the way CFML works. You need to remember you are not the steward of this language.

Also bear in mind that no-one is raising this as an issue that needs to be "fixed", so it's beyond your remit to go ahead and "fix" it.

 

Everything else is a flaw in the design of the language.

No it's not. You're taking a dogmatic view of OO which is inappropriate here. There is nothing saying an object can't exist in two states: created and initialised. It's not something that other languages do, but it's not the only thing CFML does that isn't the way that other languages do it, and this does not intrinsically make it a problem. However there is no OO axiom that prohibits this.

You are simply mapping your particular OO-interpretation preferences onto a problem that doesn't exist.

 

Because of that createObject("susi"); Is bad and we cannot change it, the only thing we can do is mark it as bad.

So hopefully I'm following your rules now .... ;-)

No, because you're still not answering the question, you're still inventing your own question and answering that.

The question - simplified - is:

Requirements:

* create a CFML object and have its init() called

* the reference to the object might be a runtime value, presented as a string (see createObject())

* the existing approach using the new keyword is unacceptable

* there are no backwards compat issues

Given the requirements, how is it my mooted solution will not resolve the problem in a CFML-friendly way?

Rules:

Just leave your rhetoric and your dogma out of it, Micha.

Just. Answer. The. Question.

-- 

Adam

[Michael Offner]

You are mapping your personaly OO preferences onto CFML, when unfortunately that boat has already sailed, and neither you, nor I, nor Sean, nor obalobbingbong (my Susi Sorglos) were consulted. Tough shit. This is not an option, so get it out of your head. Seriously: get it out of your head, it is not an option.

Of course it is a option!

You are aware that this is not the first time i did a decision like this, just a list (out of my head)

- don't pass array by value

- don't interpret variable keys

- handle this argument.key and arguments["key"] the same way

- ...

and of course there are a lot of settings in the admin where you can choose to have a different behaviour, so in the end this is the same as this option in admin, the default behaviour does not chane, but if you like to do it different ...

I think you have lost focus a little bit, we are not talking about removing createObject, if you dont care about this new function don't use them, nobody is stopping you from using createObject.

No it's not. You're taking a dogmatic view of OO which is inappropriate here. There is nothing saying an object can't exist in two states: created and initialised. It's not something that other languages do, but it's not the only thing CFML does that isn't the way that other languages do it, and this does not intrinsically make it a problem. However there is no OO axiom that prohibits this.

And if this would be a design choice of ACF i would even consider to agree with you, i could say it was a bad decision but it was decided this way so this is how cfml works. But this was never a design decision, when they added the "new" operator they did simply not change the behaviour of createObject. Adobe avoids to change existing behaviour at any coast, to make it as easy as possible to update from one version to an other. What is not always in the interest of the language.

If this would be a design choice they should make it possible to hook in before the base constructor (component body) was executed, but please not a process that stops halfway done nd you have to finish yourself.

My personal opinion always had influence on how things are done in Railo/Lucee and that will not change.

Requirements:

* create a CFML object and have its init() called

* the reference to the object might be a runtime value, presented as a string (see createObject())

* the existing approach using the new keyword is unacceptable

* there are no backwards compat issues

Given the requirements, how is it my mooted solution will not resolve the problem in a CFML-friendly way?

It does, i never said that createObject cannot be used the right way and getting a proper result in any case. That is not the point, the point is that there is a right and a wrong way with createObject, the person that does make the instance has to make sure that the instance is proper instantiated, but this is not the job of the person that makes the instance. This is a design flaw with createObject and because of that this functionality is deprecated.

I'm sure that you still will disagree because this answer has nothing I have not already written more than once but this is my position.

Micha

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/40089b3b-2241-4a36-ab5f-17dcda35d593%40googlegroups.com.

[Adam Cameron]

On Sunday, 19 April 2015 01:20:48 UTC+1, Micha wrote:

 

I think you have lost focus a little bit, we are not talking about removing createObject, if you dont care about this new function don't use them, nobody is stopping you from using createObject.

That's just specious. For one thing you said you were going to deprecate createObject(). For another thing if you add all this other crap and don't deprecate the equivalent functionality in createObject() you're making the language doubly worse.

But I'm not concerned about the deprecation of createObject(). I'm concerned about you making a pig's ear of this perceived requirement you're implementing.

 

No it's not. You're taking a dogmatic view of OO which is inappropriate here. There is nothing saying an object can't exist in two states: created and initialised. It's not something that other languages do, but it's not the only thing CFML does that isn't the way that other languages do it, and this does not intrinsically make it a problem. However there is no OO axiom that prohibits this.

And if this would be a design choice of ACF i would even consider to agree with you, i could say it was a bad decision but it was decided this way so this is how cfml works. But this was never a design decision, when they added the "new" operator they did simply not change the behaviour of createObject.

You do not know that, and cannot possibly say that. For all you know, it was a purposeful design decision because they were aware than being able to create an uninitialised object was something a lot of code leverages, and is a feature of CFML.

 

My personal opinion always had influence on how things are done in Railo/Lucee and that will not change.

Absolutely. However you also seem to think that your opinion is intrinsically right, and that your reasoning is always sound. Which it isn't. This is a case of this.

 

Requirements:

* create a CFML object and have its init() called

* the reference to the object might be a runtime value, presented as a string (see createObject())

* the existing approach using the new keyword is unacceptable

* there are no backwards compat issues

Given the requirements, how is it my mooted solution will not resolve the problem in a CFML-friendly way?

It does, i never said that createObject cannot be used the right way and getting a proper result in any case.

Well there you go. So just tweak createObject() and get rid of your other solution.

 

That is not the point,

Yes, it really is.

 

the point is that there is a right and a wrong way with createObject, the person that does make the instance has to make sure that the instance is proper instantiated, but this is not the job of the person that makes the instance.

Yes, it is.

 

I'm sure that you still will disagree because this answer has nothing I have not already written more than once but this is my position.

No, you really haven't (written before). You're still relying on a lot of your assertions being intrinsically "true", when in fact they're just an arbitrary subjective decision you've made. The next thing you need to do is to stop claiming they're intrinsically true, and acknowledge they're opinions, and entirely subjective ones.

Everyone has opinions, and that's fine, but I think we need to look more closely at those opinions and work out whether you're actually right. Which, as far as I can tell... you're not, in a few areas.

Then we need to check if there's a case to answer for. Then we need to decide how to solve it. Enough people think the current way is a variation of wrong, incomplete, ill-advised, or some variation of all those (and on grounds you've mostly deflected from rather than addressing) for the solution to be taken back off the table and revisited.

To deprecate close to core functionality in the language you need a very solid case. To implement functionality as new functions which overlap with existing function you need a very solid case. And then then implementation needs to be adequately thought through too (which clearly it isn't, as it's already undergone two name changes in the space of a week).

Basically whether or not the need for this change is needed is still far too unclear for the change to have been put in the language already.

-- 

Adam

[Adam Cameron]

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

[Andrew Penhorwood]

Your points cover the discussion well.  I just want to know what I can use in code be that CFML or Lucee going forward.

I like the 3 functions approach (component, java, webservice).  Name them what you want just let me know what they are called.

The bigger picture and maybe the real points of contention: Incomplete / missing documentation, no view into the process of language development and no clear definition of terms.  But I will start a new thread for my thoughts on these.

Andrew Penhorwood

[Brad Wood]

...you also seem to think that your opinion is intrinsically right, and that your reasoning is always sound. 

Pot meet kettle?  You've been berating and belittling Micha this entire thread, giving him silly "rules" (that basically force him to only provide an answer you deem acceptable) as though you're his school teacher.  I think you need to admit that Micha has answered the question and he's answered it fully.  Just because you don't agree with the answer doesn't invalidate it.  And your response to the one other person who tried to share their opinion will only ensure that no one else bothers chiming in with their opinion lest they get torn apart as well.  

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

Lucee has stated a preference to not modify CFML (Adobe's language) anymore.  Improvements will be made going forward in the Lucee dialect.  I think that's reason enough not to do that.  Sure, it COULD be done, but that's not reason enough to do it.  I agree with Micha that three, dedicated methods are more equipped to serve than one overloaded method.

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

Micha is right.  Honestly, I'm surprised at your take on this one Adam.  You're always calling CFML developers to balls up and learn the correct way regardless of what horrid precedents may have been set in the past.  Any OO language out there that I'm familiar with will call the constructor by default and it's a glaring flaw that CFML doesn't.  I can assure you there was no 'good reason' back in the day for this.  It was a simple matter of Macromedia half-implementing OO, nothing more.  This is proven by fact that the "new" keyword" and "entityNew()" BIF both call init which is the correct behavior.  createObject has only been left that way for backwards compat.  You've written entire blog series on how a "10 year precedent" is meaningless and Adobe should fix broken stuff (isvalidk dates, etc) but now suddenly why are you so attached to the lack of init()?  I've never seen anyone have an init method but not call it on purpose and if they did, it's because they're confused about proper OO.

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

I think it's a fantastic approach to clean up the language.  As a reader of Uncle Bob, I'm also surprised at your opinion on this one.  In Clean Code, Uncle Bob is all about removing vague, multi-purposed, overloaded methods in favor of several clean and specific methods that do a single thing well.  I think this follows that principle and leaves Adobe's CFML untouched at the same time.

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

I believe they already have, so let's move on and stop making a mountain out of a molehill.  It's been explained very clearly at this point.

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

Adam, that's VERY clearly not what was intended as has been stated over and over.  Why would you continue to propagate that false interpretation? You're creating smoke and mirrors!  To be honest, there are only really 3 "framework authors" in the CFML community.  Sean is very bright so I'm sure he will have no problem now that the term has been defined.  ColdBox also completely understands that there is no issues to be had.  We haven't heard from CFWheels, but they're smart chaps as well so I don't foresee them being confused either.  Let's stop using "poor confused framework authors" as leverage.

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

I personally don't think it should be touched.  It's Adobe's function and changing its behavior would be more confusing than not.  And again, see the Uncle Bob references.  Three, specific functions with set parameters are better than a single, overloaded multi-purpose function.   

Accordingly [createobject] cannot be deprecated.

It can and it has.  The need for it's current implementation is grounds for not REMOVING it.  There's nothing preventing us from telling people it's old and crusty and we don't recommend it. 

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

False because your assertion based on a false premise.  But even if we DID "fix" createobject() I still would agree that three new and specific methods would be a step forward in the Lucee language. You're pretending those options are mutually exclusive. 

Unless any of us who have already offered our 2 cents have something actually new to add other than "I disagree" (which is already apparent) I'd recommend leaving this thread for others to now get a word in edgewise :)

Thanks!

~Brad