createObject(). Focused question

dev google-group-archive
1

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

2

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()On Saturday, 18 April 2015 08:21:00 UTC+1, Konstantinos Liakos wrote:

–
Adam

3

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

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 manyAm Samstag, 18. April 2015 schrieb 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

–
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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/58912dc1-89b0-435b-aa5d-3244f70bfeb9%40googlegroups.com
https://groups.google.com/d/msgid/lucee/58912dc1-89b0-435b-aa5d-3244f70bfeb9%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

4

I did, but try me to do it with other words :wink:

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 … :wink:

MichaAm Samstag, 18. April 2015 schrieb 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

–
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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/e68914fc-5652-4c04-a16a-d66dbe03e8e5%40googlegroups.com
https://groups.google.com/d/msgid/lucee/e68914fc-5652-4c04-a16a-d66dbe03e8e5%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

5

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

Adam Cameron's Dev Blog: Survey results: A quick OO terminology survey

This is the answer:

I answered this in detail in the first comment of this blog post
http://blog.adamcameron.me/201…
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 …

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).On Saturday, 18 April 2015 21:46:03 UTC+1, Adam Cameron wrote:

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

6

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?On Saturday, 18 April 2015 09:58:57 UTC+3, Adam Cameron wrote:

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

7

I did, but try me to do it with other words :wink:

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 … :wink:

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.On Saturday, 18 April 2015 22:38:24 UTC+1, Micha wrote:

–
Adam

8

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

9

I answered this in detail in the first comment of this blog post
Adam Cameron's Dev Blog: Survey results: A quick OO terminology survey

This is the answer:

I answered this in detail in the first comment of this blog post
http://blog.adamcameron.me/201…
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 …On Saturday, 18 April 2015 20:10:53 UTC+1, Micha wrote:

10

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.On Apr 18, 2015 3:05 PM, “Adam Cameron” <@Adam_Cameron> wrote:

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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/dc04388f-fe6b-4d24-b894-06c438a4113d%40googlegroups.com
https://groups.google.com/d/msgid/lucee/dc04388f-fe6b-4d24-b894-06c438a4113d%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

11

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.On Saturday, 18 April 2015 13:39:37 UTC+1, Konstantinos Liakos wrote:

–
Adam

12

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.

MichaOn Sat, Apr 18, 2015 at 11:59 PM, Adam Cameron <@Adam_Cameron> wrote:

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

I did, but try me to do it with other words :wink:

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 … :wink:

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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/40089b3b-2241-4a36-ab5f-17dcda35d593%40googlegroups.com
https://groups.google.com/d/msgid/lucee/40089b3b-2241-4a36-ab5f-17dcda35d593%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

13

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.On Sunday, 19 April 2015 01:20:48 UTC+1, Micha wrote:

–
Adam

14

…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 :slight_smile:

Thanks!

~Brad

1 Like
15

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

16

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? :wink:

  • 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 :wink:

Thoughts?–
Adam

On Saturday, 18 April 2015 07:58:57 UTC+1, Adam Cameron wrote:

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