CFInvoke fails calling method inside component about openbluedragon

[GoogleCodeExporter]

I am confused...

Why does the parent, need to know about the child? Does anyone agree that the 
parent 
SHOULD not know about its child?

If you are going to extend a component, the parent is what is considered common 
code 
to other components to override or enhance.

The problem here is that if I CreateObject('component',parent') it is goinf to 
error 
because the child WILL not be defined. If this is allowable in ColdFusion 8 
then 
that would be considered a bug to me.

Could you provide a very good reason why you would want the parent to call the 
child?

Think about the OOP side of what you are doing and you will see that what you 
are 
trying to do is considered illegal, why because you are putting a condition 
that can 
and may not exist.

Me, instead of calling super then and reinvoking a child. Move the code into 
the 
child and you will be right.

I can not think of one reason why you would do what you are doing. Just because 
COldfusion 8 allows it doesn't make it right either.

Anyone else?

Original comment by [email protected] on 17 Aug 2008 at 9:37

[GoogleCodeExporter]

There are lots of things that CF lets you do that doesn't equate to good 
programming
practices.

Webflint, thanks for reporting the issue and supplying the test case. I've 
verified
that it's a compatibility issue.

Original comment by [email protected] on 18 Aug 2008 at 1:14

• Changed state: Accepted

[GoogleCodeExporter]

That is true, but let me ask you this. Is it listed on Adobe coldfusion as a 
bug?

If it isn't then it might not have been reported as such, I realise that 
Coldfusion 
doesn't alwasy equate to good programming practices. But the point I guess I 
was 
trying to make I believe in the fact that this behavious could change in 
ColdFusion 
in the future if it is reported to be a bug.

I know you guys have made it very clear in the past that just because 
Coldfusion 
allows doesn't mean that openBD should.

I am sorry, but I disagree with this. The extends is there for OOP style in 
ColdFusion, just because they haven't got it right doesn't mean openBD should 
do the 
same.

If it was me I would be highlighting this to Adobe and partition to get it 
fixed, 
because it does encorage bad programming and also encourages too much confusion 
when 
such developers are trying to come to grips with OOP.

This will just confuse them more.

Original comment by [email protected] on 18 Aug 2008 at 1:21

[GoogleCodeExporter]

Andrew, I think a valid use of this sort of construct in OOP terms would be to 
think 
of "foobar" as an abstract function. That is, "parent.cfc" is basically 
requiring 
that any subclass implement the "foobar" function, otherwise you'll get a 
runtime 
error. Different subclasses could provide different implementations of "foobar".

Note that BlueDragon and OpenBD support the formal concept of abstract 
functions; 
since ColdFusion doesn't, this is the only way to do it.

Original comment by [email protected] on 18 Aug 2008 at 4:16

[GoogleCodeExporter]

Very valid point.

Original comment by [email protected] on 19 Aug 2008 at 4:44

[GoogleCodeExporter]

The problem seems to just exist with CFINVOKE. As a workaround, the following 
code 
in parent.cfc:

  <cfinvoke method="foobar" />

can be replaced with this:

  <cfset foobar()>

or this:

  <cfscript>foobar();</cfscript>

Original comment by [email protected] on 19 Aug 2008 at 6:52

[GoogleCodeExporter]

One more discovery: this bug only happens when a subclass function invokes a 
superclass function that then tries to use CFINVOKE for a subclass function. If 
a 
superclass function directly invokes a subclass function--without first being 
invoked by a subclass function--then it works. For example, if you comment-out 
the "test" function within "child.cfc" so that "test" within "parent.cfc" is 
called 
directly from "test.cfm", then it works.

Since this is a fairly oddball edge-case, and there's a workaround, and the 
solution 
looks like it's going to be fairly tricky, it doesn't look like there's going 
to be 
a fix available in the near-term.

Original comment by [email protected] on 20 Aug 2008 at 3:37

[GoogleCodeExporter]

sorry I am late to the comments.  Some thoughts on this issue, with a pitch to 
get it
fixed sooner than later.

The issue also exists if foobar() is defined in the parent.cfc and child.cfc. 
calling foobar() from parent.cfc will execute the foobar function in 
parent.cfc, even
though it is overloaded in child.cfc.

So I am prevented from overloading functions from extended components ( this is
specific to CFINVOKE still though )  

We have to use CFINVOKE in our instance, which makes the fixing of this issue
important to us.  The advantage to using cfinvoke is that it allows the Method
attribute to be dynamic.  So we actually do something like this:

<cfset foobarFunction = "foobar" />
<cfinvoke method="#foobarFunction#" />

I am not sure there is a work around for that without serious refactoring.  

thoughts?  comments?

thanks.

.brett

Original comment by [email protected] on 3 Sep 2008 at 9:51

[GoogleCodeExporter]

I personally don't like this behaviour.

The reason being is that people are not understanding parent instance and child 
instance, if one is to instantiate a child and call a super method thats all 
and 
dandy.

A parent, should not know about the child and what it does overload or not. Let 
me 
define it this way.

I have two classes, a bike class and a wheel class. The bike class doesn't care 
whether it has wheels or not, not should it ever require you too. The wheels 
class 
extends the bike class (bike is parent), it now has all the methods for 
controlling 
the wheel, as well as controlling the aspects of the bike itself.

The point being, is that to call something that may or may not get overloaded 
is a 
crock of shit. This in my opinion begins to lend itself to very bad coding 
practicies, and will eventually cause more headaches and maintenance issues 
when 
Adobe begin releasing true OOP in the syntax.

I am sorry, I DO NOT see this as being needed to be fixed. What it needs is to 
introduce, proper OOP syntax and principles and not allow for bad habbits.

Sorry for the rant, but I still don't see the need for this to work.

Original comment by [email protected] on 10 Sep 2008 at 2:28

[GoogleCodeExporter]

May I add, that if one wants to provide abstract or interfaces then provide it 
in 
the language itself. Don't look for quirks in the language to do the something, 
that 
could be identified as a bug and fixed.

I can safely say that, with the next release there are things like this that 
will 
break. Does that now mean it is no longer a compatability issue, because 
Coldfusion 
now uses abstract and interfaces, properrly? Then other engines like openBD 
have to 
then identify it as a problem again and refactor the unsupported changes to the 
language?

I tell you know I will be watching this one with curiosity to see how it is 
fixed / 
implemented. And watching with intent on how the team will move forward with 
this.


I guess I am saying don't bandaid solution it, fix it properlly.

Original comment by [email protected] on 10 Sep 2008 at 2:36

[GoogleCodeExporter]

FWIW: Railo does not have a problem with this type of "abstraction"

Original comment by [email protected] on 10 Sep 2008 at 8:39

[GoogleCodeExporter]

I found the work around for CFINVOKE is to use the component attribute to 
reference
the component reference:

<cfinvoke component="#this#" method="foobar" />

Original comment by [email protected] on 9 Oct 2008 at 12:27

[GoogleCodeExporter]

just a note that the work around won't allow execution of functions that are 
private
or outside of the package ( if the parent.cfc is outside of the child's package 
).  

This seems to be correct, and not a true work around.

Original comment by [email protected] on 9 Oct 2008 at 12:38

[GoogleCodeExporter]

I found a better workaround than what is listed in comment 12.  One can use 
evaluate
to call a function with a dynamic name:

in parent.cfc call foobar like this:

  <cfset var myFunction = evaluate ( "variables.foobar") />
  <cfset myFunction() />

Original comment by [email protected] on 29 Apr 2009 at 11:05

[GoogleCodeExporter]

Original comment by wheldon.greg on 23 Jan 2010 at 10:09

• Changed state: WontFix