tracker issue : CF-3909707

We need a repro, Ray. As discussed, this works fine for me: <cfscript> cfwddx(action="cfml2wddx", input={}, output="w"); writeDump(var=variables); </cfscript> -- Adam

Comment by External U.

Yep, you are right. The entire issue was that I did: x = cfwddx(action="cfml2wddx", input="something") the x= must have confused the parser. I do think the error should have been clearer though. At worst, shouldn't it have worked, but X simply be undefined?

Comment by External U.

I wish the tag-to-script functions actually returned results w/o having to pass the result name as a parameter. Thanks!, -Aaron

Comment by External U.

Well, Aaron, a few other things to consider first: a) accept that tag-based code is entirely different in design to script-based code; b) don't simply implement tags with no angle brackets and go "look! 100% script coverage!" (because that just makes Adobe look like lazy, clueless oiks); c) don't prefix everythig with "CF". WE GET IT, IT'S CFML. No other bloody language prefixes its constructs with the vendor name!!! What the hell is wrong with you people? d) do the work properly, and implement the functionality for CFScript *properly* and like professionals. *Then* we get to: e) yeah, something that looks like a function should return a value, not expect one to pass a string in which is then magically used to create an undeclared variable in the calling code.

Comment by External U.

Hi Adam, The "CF" prefixing always had me thinking about something. I've always wanted to create my own built-in-functions. Currently, I avoid any future naming conflict by prefixing my UDF names w/ "udf" (ex: udfIsFoo()). But it'd be sorta neat to be able to create my own "isFoo()" function too. If CF ever allows us to extend the language w/ our own true BIFs, hopefully our isFoo() would trump CF's isFoo(). If CF is insistent on trumping our BIFs w/ its own BIFs, then the "CF" prefixing may come in handy there. But surely CF would allow our BIFs to trump its own? In that case, I'm sure the "CF" prefixing could just be done away with. Thanks!, -Aaron

Comment by External U.

Hi Adam, Looking at the "CF" prefix from another angle, it looks like there'd possibly have been some naming conflicts if the "CF" prefix hadn't been used: BIF vs tag-to-script ---------------------------------- fileupload() vs fileupload() insert() vs insert() invoke() vs invoke() location() vs location() log() vs log() throw() vs throw() trace() vs trace() Since location(), throw() and trace() all accept named parameters identical to their tag counterpart, it appears there'd have been no issue w/ these. Well, except for the trace() BIF not properly supporting a body (#CF-3811003). fileUpload() could've been resolved by allowing the BIF to accept named parameters. invoke() doesn't transiently instantiate a web service object (#CF-3864527), nor does it support a body (thus doesn't support an invokeargument() (#CF-3863516)) - so <cfinvoke> would've probably had to have been named something other than invoke(). insert() and <cfinsert> differ, as does log() and <cflog>, so <cfinsert> would've had to have been named something other than insert() and <cflog> would've probably had to have been named something other than log(). Just thought I'd check to see what might've conflicted. Thanks!, -Aaron

Comment by External U.

Please disregard the "<cflog> would've probably had to have been named something other than log()" b/c writeLog() already exists.

Comment by External U.

In short, it looks like the "CF" prefix could've been avoided if: 1) trace() properly supported a body 2) invoke() could transiently instantiate a web service object and supported an invokeargument() 3) <cfinsert> and <cfupdate> became something like dbInsert() and dbUpdate() Thanks!, -Aaron

Comment by External U.

Geez.. forgot about the <cfdirectory action="list"> vs directoryList() issue. :/

Comment by External U.