Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at CFinNC 2009 (Raleigh, North Carolina) with:

ColdFusion 10 Beta - Miscellaneous Parsing Bugs And Oddities

By Ben Nadel on
Tags: ColdFusion

As I've been poking around in the ColdFusion 10 beta, I've come across a few parsing bugs and oddities. I blogged before about a critical bug with function expressions; and, I'm happy to report that the bug has already been fixed internally for the next ColdFusion 10 build. The following are some more parsing bugs and oddities that I have found.

Return Statements And Implicit Notation

While the return() statement is not a "function" call, I tend to use the "()" notation when executing it. I just like the way it looks and I believe it does a better job of delimiting the code. Unfortunately, it looks like you cannot use the parenthesis if you are returning a value that is defined using implicit notation. That is, you cannot use "return()" in conjunction with implicit arrays, implicit structs, or function expressions. None of the following return statements parse:

  • <cfscript>
  •  
  •  
  • // None of the following three return() statements work when used
  • // in conjunction with implicit-notations for ARRAY, STRUCT, and
  • // CLOSURE. Must return "( )" from return statement in order to
  • // parse properly.
  • function returnImplictNotation(){
  •  
  • return( [ ] );
  • return( { } );
  • return( function(){ } ) ;
  •  
  • }
  •  
  •  
  • </cfscript>

All of these return() statements throw a parsing error. If you simply remove the "()" portion of the return statement, however, they run properly.

Function Expressions In Implicit Structs And Arrays

You can assign function expressions to variables; you can assign function expression to properties; you can put function expression in arrays; you cannot, however, define function expressions as part of an implicit struct or an implicit array notation. None of the following implicit construct statements parse:

  • <cfscript>
  •  
  •  
  • // Function expressions / closures cannot be defined in the
  • // context of an implict struct.
  • udfs = {
  • doThis: function(){ },
  • doThat: function(){ },
  • };
  •  
  •  
  • // Function expressions / closures cannot be defined in the
  • // context of an implict array.
  • callbacks = [
  • function(){ },
  • function(){ }
  • ];
  •  
  •  
  • </cfscript>

All of these implicit notation statements throw a parsing error.

Invoking Methods Using Thread Attributes Scope

This is a really strange error. It's not a parsing error - it's some sort of context evaluation error. If you pass values into a CFThread tag using the tag attributes, you can access those values from within the CFThread tag body using the "Attributes" scope. However, if the value is a function or a function expression, the function cannot be invoked off of the "attributes" scope.

  • <cfscript>
  •  
  •  
  • // Define our UDF to pass into the thread.
  • doSomething = function(){
  • // ...
  • };
  •  
  •  
  • // Spawn a thread and pass-in the UDF as an attribute.
  • thread
  • name = "testFunctionCall"
  • action = "run"
  • udf = doSomething
  • control = "Simple Value"
  • {
  •  
  • // As a "control", export the simple value.
  • thread.control = attributes.control;
  •  
  • // Invoke off of attributes -- for some reason, this throws
  • // an error (regardless of whether or not the given function
  • // is a standard function or a closure). It can be invoked
  • // without scoping... but NOT with it.
  • attributes.udf();
  •  
  • }
  •  
  •  
  • // Join the thread so we can see the output.
  • thread action = "join";
  •  
  • // Outpu the thread properties.
  • writeDump( cfthread );
  •  
  •  
  • </cfscript>

As you can see, we're passing in a control [simple] value and a closure into this CFThread tag. We are then executing attributes-scoped access on each value. When we run the above code, the "attributes.control" statement works; but, the "attributes.udf()" throws the following error:

Either there are no methods with the specified method name and argument types or the udf method is overloaded with argument types that ColdFusion cannot decipher reliably. ColdFusion found 0 methods that match the provided arguments. If this is a Java object and you verified that the method exists, use the javacast function to reduce ambiguity.

If you remove the "attributes." scope from the udf() invocation, it works perfectly.

So far, I'm really loving the ColdFusion 10 features. There's just a few parsing bugs that need to be ironed out before the next public release.




Reader Comments

This doesn't work either, but does work in Railo 4:

myFunction(
function() {
return '';
},
function() {
return '';
}
)

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.