An intriguing (to me) and useless question about CFCs

[WolfShade]

Hello, all,

CFCs.  Some of us love them (I DO), others not so much, maybe.  But I'm curious about something.

I recently posed a plea for help while just learning if something were possible in CF:  a dispatch table.

Basically, a dispatch table is an object that can perform boolean comparisons, much like a switch/case, but there's no string comparison - you drill straight to the object property.

Which, now, makes me wonder.  Is a CFC like a dispatch table (the various CFFUNCTIONs are properties of an object, ie the CFC), or more like a large switch/case (the various CFFUNCTIONs just the equivalent of <cfcase value="myFunctionName">...</cfcase>, in which string comparisons are performed in order to get the correct code)?

Just curious.

V/r,

^ _ ^

[Dave Watts]

I don't know whether this answer is useful, but each CFFUNCTION is compiled into its own class as if it were a .cfm file. There's no corresponding class for the entire .cfc itself, as far as I know.

Dave Watts, Eidolon LLC

[Charlie Arehart]

Dave, I can confirm that a cfc does indeed create a class file, then one for  each method, as you said . Same for cfm files and each function in one. 

But as for wolf's question, I have no idea  

[BKBK]

A CFC is neither like a dispatch table nor like a switch/case construct. That is because the engine that ColdFusion uses to build CFCs is Java. Java doesn't have pointers, which are required in the use of a dispatch table. A switch/case construct would be inefficient at compiler level. One reason is that it would in theory allow non-unique cases.

Nevertheless, I think that ColdFusion, or rather its underlying Java engine, uses techniques similar to the dispatch table and switch/case when it processes a CFC. As Dave and Charlie have said, the CFC is compiled to a class, as is each of its functions. I would add that ColdFusion gives the classes unique names. It then uses these, within the CFC class, to create an object from the class corresponding to each function. In Java, each such object corresponds, at runtime, to a unique reference (compare with pointers in a dispatch table or cases in switch/case).

[WolfShade]

BKBK,

Thanks for the explanation.  However, if I follow your input correctly, would it not then follow that a CFC is an object of objects?

I know nothing of classes (in either CF or JavaScript.. from what I've read, classes in JS are simply "syntactical sugar over prototype".  I assume they are the same in CF/Java.)

V/r,

^ _ ^

[Dave Watts]

"would it not then follow that a CFC is an object of objects?"

Not really, in the strict programmer's sense of the word "object". It's a file, it contains a bunch of other files, and in Java those files do correspond to objects. But you don't really use them as objects, because the object-ness of them is hidden behind a veneer of other stuff that is what you actually use. You're not writing Java code, you're writing CF code, and from your perspective you don't see functions as objects.

"classes in JS are simply "syntactical sugar over prototype".  I assume they are the same in CF/Java."

Not really. In JavaScript, before we had classes, we had prototypes. These were basically objects (not templates) that we could use to create new objects. Because they were actual objects themselves, they could be modified at run time, and all kinds of wacky fun could result! I'm glossing over the details here, but the way to learn more about this subject is to search for "prototype vs class based inheritance". In short, JavaScript has really always been an OOP language, it just approached its objects in a different way. The idea of prototype-based inheritance was that you didn't need to compile anything and that it was simpler to learn if you had no OOP background. CF, on the other hand, didn't have classes or prototypes for most of its existence. OOP in ColdFusion has been tacked on pretty recently. The same is true for PHP. So, they're not really syntactical sugar - there's a lot of stuff going on with OOP that couldn't be done without it: inheritance, etc. Prototypes provided inheritance already, for example.

Dave Watts, Eidolon LLC

[WolfShade]

Thank you for the clarification, Dave.  I will look up prototype vs class based inheritance, as suggested.

V/r,

^ _ ^

[BKBK]

WolfShade  wrote

BKBK,

Thanks for the explanation.  However, if I follow your input correctly, would it not then follow that a CFC is an object of objects?

No, a CFC is essentially a class, not an object. The class contains fields (which you may call objects), each of which is an instantiation (new Somethn()) of a class corresponding to a method.

[BKBK]

A test you might like to do in your development environment (for CF on Windows):

1) Download and install Java-Decompiler;

2) Create a folder called classTest in your ColdFusion project (within a test CF instance) and place the following 2 files in it

testPage.cfm

<cfscript>

    obj=createobject("component","Test");

</cfscript>

Test.cfc

component  displayname='Test' name='Test' accessors="true"

{

    property name="property1" type="numeric" default="1" ;

    property name="property2" type="string" default="two" ;

public any function init( ) {

    return this;

}

public numeric function function1() {

    return this.property1;

}

public string function function2(){

    return this.property2;

}

public numeric function myFunction(numeric x ) {

    return arguments.x;

}

}

3) Go to the CF Admin of your ColdFusion instance and switch on the option to save class files;

4) Go to the folder wwwroot/WEB-INF/cfclasses of your ColdFusion instance. Delete all the files in it. (If there is no cfclasses folder, create one.)

5) Restart the ColdFusion instance.

6) Return to wwwroot/WEB-INF/cfclasses of your ColdFusion instance and delete any files in it.

7) Run the CFM page above. ColdFusion should then generate 6 class files in wwwroot/WEB-INF/cfclasses, each having a name starting with cfTest, for example

8) Launch Java-Decompiler and use it to examine the contents of the class files.