Tuesday, 22 July 2014

I'm sick of vendors screwing up CFML


How hard does any of this need to be? I'm posting this here and against the Railo bug report I started typing it into "CFHTTP accept callback UDF to report progress" (RAILO-3131). As it's stroppy, Micha should feel welcome to delete it from Jira. However it's staying here.


Brad raised this:
Allow CFHTTP to accept a closure which will be called every time 1% of the file has been downloaded. Include the size so far, total size, current percentage, and possibly a KB/s measurement in the data available to the closure. Perhaps the closure could simply be passed the cfhttp structure that is normally available at the end of the call, but it would be populated with the data available so far (including status code, headers, etc, and any new values necessary such as percent done.)

<cfhttp method="Get"
    progressUDF=function( cfhttp ) { ... Alert the user ... } >

Excellent suggestion. I suggested this:
I'm all for this sort of functionality being added to the language, but perhaps at a broader level. There's nothing wrong with Brad's approach when taken in isolation - it's a good idea - but there is probably a "bigger picture" that can be looked at when it comes to async programming.

And Micha then added this:
small addition: Railo 5 will have a tag named "cftask", this will be a lightway version of . In other words Railo will create a task that get executed asychron, like cfthread-task this task is persistent, means it does survive a restart of the engine.
<cfhttp ...>
<!--- handle cfhttp result here --->
My reaction to that was one of horror, and I returned:

Please please please don't add this as a tag. Add it as a function which takes a function, eg:

    // stuff goes here
The functionality is fine, but it's simply not a tag. it doesn't make sense as a tag. It should not be implemented as a tag. If it's implemented as a function, we don't need two different versions: a function will work in both tags-based code and script-based code.

Micha's fed back with some facile nonsense, and I have become non-plussed. I'm adding this one last comment, and then moving on. I've tried.

You really let yourself down with obtuse rationalisations like suggesting the component keyword is a tag. It's not, in any way that a sensible person would define it. So let's dispense with that, shall we? Good.

Your suggestion requires two language constructs:


Mine just requires the one function for both purposes:

<cfset runTask()>

One doesn't need two constructs. You're the one cluttering the language, not me.

This is the reason why I think Railo's entire approach of implementing CFScript "equivalents" of tags simply by swapping out <cf and > is fuckedflawed. It's just making CFML even more bloody idiosyncatic than it already is with its tag-heavy corpus. Now we have idiosyncratic "tags", and idiosyncratic "tags without angle brackets" (which is even worse than the tags are!). Both are a shitty construct, and the latter were a lazy solution to the perceived problem that CFML needs all tags represented in CFScript. As I've said before... it's not the tags that CFScript needed, it was the functionality. Railo have been very "Adobe" in their approach to implementing the "missing" functionality from CFScript.

TBH, I think two - fairly controversial - things:

  • deprecate all this "tags" without angle-brackets nonsense in Railo's CFScript solution, and re-work it properly with well-thought-out, situation-specific and elegant solutions;
  • form a language design committee to lead the direction of the language, in which Micha has a vote, but doesn't make the final decision. There's been a few poor ones, recently and I think he's out of his depth.
I decided that a while ago, but I thought it was a fairly controversial suggestion so I kept the audience to that particular thought fairly small. But... well it's perhaps time to put it out there as a suggestion.