Lists with empty-string delimiters

G'day:
Blimey; three articles today. Once again, this stems from a thread on the Railo Google Group, this time regarding a bug I found in Railo (or that I think is a bug), which resulted in some questioning whether it's a bug in Railo, a bug in ColdFusion, or a bug in both. And the more I look into it, the less sure I am about it.

And the situation I found the... erm... "anomalous  behaviour" (shall I say) was in the code I was writing for the previous two articles' investigation.

Don't optimise your code (annexe)

G'day (again):
In the previous article I alluded to the fact I had more to say on the approach I had to creating my test strings for those experiments. This'll just be short, as it's a variation on the same theme, and I just thought I'd share this with you.

For the previous tests I saved a million-char randomly generated string to test on. Whilst writing the code for this, I noticed some significant performance differences in various different techniques I was using to build the string.  And these are perhaps worth remembering, as far as potential optimisations go.

Don't optimise your code

G'day:
Well that headline is a gross over-simplification of what I'm going to say here. Obviously one should write code that's optimal for the task at hand, but there's a time and place for doing this sort of thing.

The Railo Google Group seems to be my muse this week (which is a sorry indictment of me on a coupla levels), after yesterday's [ed: it was y/day when I started this, it was a few days ago now] inspiration regarding making CFML built-in functions "first-class", and now this article about premature optimisation.

Callbacks and built-in functions as first-class functions

G'day:
This will be my most unplanned blog article to date. I saw a thread on the Railo newsgroup over Xmas, and whilst catching up with my responses just now, decided "oh, I'll be able to come up with an article about that".

The posting on the mailing list was asking whether one can pass a built-in function (BIF) as a callback.

I currently have no idea what I'm about to say about this, so I am as interested in what I continue to type as you are (the conceit is that if you've got this far, you have at least a small amount of interest)...

More balance, fewer @rseholes

G'day:
There's been a bit of back-and-forth on Twitter (nothing of any merit, sadly) regarding my posting from the other day regarding some "shortcomings" in the attitude of some of the users on Stack Overflow, and also - given how said users behave - some potential areas for improvement in the Stack Overflow process.

I don't contest that the first part of the article was quite vitriol-laden, and that was by design. However later in the article I did try to discuss - in an objective, balanced way (? well, mostly) - where I think things could be improved.  However I think I did not succeed in the objectivity, or some people didn't get past the headline, or if they got that far, didn't read past the vitriol. I am guilty of doing this (to myself) in my writing sometimes.

Anyway, the article was put on the twitter radar of one of the blokes who started Stack Overflow (thanks Stephen Moretti for thinking to do that), and there was a brief exchange between myself and Jeff Atwood (the S/O bloke) and some others. I think Jeff was a bit defensive, but in his defence, I can see how he'd find my article incendiary. And equally my responses to him could have been more diplomatic. Well the ones I made just now, anyhow. I'll leave it to you - the reader - to dig it up in my Twitter history if you so choose. It's not very exciting.

So, here I am again. What I'm going to try to do in this article is to articulate my point differently:

• no vitriol, snippiness, back-handedness or passive aggressiveness (this will be a stretch for me, as you can imagine ;-)
• maintaining objectivity (OK, that's a variation on the above);
• trying to convey my thoughts more clearly than I have previously.

The very first thing I'd like to say is I really like Stack Overflow! Jeff, if you only glance at this article before dismissing it, hopfully you'll see that bold red bit there.

Regular expressions in CFML (part 5: syntax - look-arounds, and how the engine parses the string it's matching)

G'day:
This is part five of the series I started with the introduction article: "Regular Expressions in ColdFusion (part 1: overview)", and followed with a discussion entitled "Regular expressions in ColdFusion (part 2: concepts)". Then I moved onto syntax with "Regular expressions in ColdFusion (part 3: syntax - single characters)" and "Regular expressions in ColdFusion (part 4: syntax - repetition, sub-expressions and back-references)".

Please note that this article - more so than the other ones - does not stand-alone. It's more a "part 2" of the preceding article. I advise reading at least that one before reading this one. But, really, one should read the whole lot in order. But bring food and water with you before starting.

Look-arounds

Another type of sub-expression is a look-around. Look-arounds do what the name suggests: they look around to see if there's a match (or there specifically isn't a match). They can look ahead from the current position in the string being processed, or they can look behind. So we have four different sorts of look-around:

• positive look-ahead;
• negative look-ahead;
• positive look-behind;
• negative look-behind.

ColdFusion's regex engine only supports look-aheads (both positive and negative ones).

Before I explain how these work, let's back up a bit and examine what goes on when a regular expression pattern matching exercise takes place on a given string.

Christmas Spirit, StackOverflow style (#2 in a list of why StackOverflow is populated by @rseholes)

G'day:
Is it the season for "Peace on Earth and goodwill to all men"? No, on StackOverflow it's more like "Screw you, newbie @rsehole: I have power over you, die die die" for some people. And, again, people like this demonstrate how the Stackoverflow approach to site self-management needs some thought.

NB:
If you read this article, also please make sure you read the follow-up to it as well.

A newbie ColdFusion user has posted a newbie-ish question over on Stackoverflow. Given the treatment they've received from non-ColdFusion users over there, I would not be surprised if it's their last.  Here's a summary of their question (by someone called "volume one"):

Regular expressions in CFML (part 4: syntax - repetition, sub-expressions and back-references)

G'day:
This is part four of the series I started with the introduction article: "Regular Expressions in ColdFusion (part 1: overview)", and followed with a discussion entitled "Regular expressions in ColdFusion (part 2: concepts)". Then I moved onto syntax with "Regular expressions in ColdFusion (part 3: syntax - single characters)".

Repetition (again)

In a previous article I listed the types of repetition one can express in a regex:

• Zero times
• Zero or one times
• Zero our more times
• One time
• One our more times
• An exact number of times
• Between a specified minimum and maximum number of times
• At least a minimum number of times

Regular expressions in CFML (part 3: syntax - single characters)

G'day:
This is part three of the series I started with the introduction article: "Regular Expressions in ColdFusion (part 1: overview)", and followed with a discussion entitled "Regular expressions in ColdFusion (part 2: concepts)".

Syntax

OK, so I'm now going to try to describe how all those concepts are actually reflected in regex syntax. This is where I am going to dispense with most of the keys on the keyboard, and just use the punctuation keys ;-)

(not really)

I'll go through each of those concepts in turn.

Need help? Know how to ask for it

G'day:

This article is borne out of exasperation rising from dealing with people on StackOverflow. But this time not the nazi muppets who like to think they are in a position of authority (and they're at it again today…), but the people asking the questions. To be fair: not all the people asking the questions, but a reasonable percentage of them. An uncomfortably high percentage of them. And the same extends to people asking questions on the Adobe ColdFusion forums, and other similar environments created for people to seek and get help.

I never cease to be amazed at how bloody useless people are at asking for help. And continue to marvel (not in a good way) at how disconnected from reality people must be to approach asking for help the way they go about it. And even before getting to the point of asking for help, how lacking in gumption people can be when it comes to trying to solve their own problems before expecting someone else to pitch-in and help them.

Before I start ranting too much (some might say "too late!" but I've only just started, trust me)… I enjoy participating on help forums. I've been doing it since I first located the alt.comp.lang.coldfusion Usenet group in 2001 (I started with CF in late 1999).  I enjoy the feeling I get when I've successfully helped someone move past a problem (both for myself, and knowing that the other bod will be pleased to move on from this stumbling block they'd encountered); I like the selfish sense of satisfaction I get when I work something out that someone else couldn't work out (I'm not proud of this, but I'm a realist, and it is a factor); most of all I like it when I initially don't know the answer to something I'm trying to help with, and end up learning something as a result. It also helps the ColdFusion community keep ticking over, which Adobe kinda leave up to us to do, so that's gotta be good for ColdFusion's viability going forward. Albeit in a very small way. But community activity is important to the viability of the language, I think.

Anyway, as much as I enjoy it, boy do I find it irritating at times. You probably got that already.

OK, so what's the problem?  Actually the problem is basically described by inference in this distillation of how to ask questions the smart way. It should be required reading for anyone signing up to a help forum. It should be required reading for everyone working in technology. Go read it. Now. But here's my take on where people go wrong when they encounter a problem they don't know the answer to, and where they start going wrong right from the outset.

Identify the problem

If you encounter a problem - like getting CF error on your screen - approach solving it coherently. A lot of people when they get bamboozled by an error simply start trying random things to try to solve it: "I'll restart CF and see if that helps". "I'll use a list instead of an array". "I'll just rewrite it, maybe it'll go away". This is a daft approach to solving things. Even if the problem does happen to go away, you probably won't end up knowing what the problem was, so you really can't be sure it's not some sort of transient problem that didn't just not occur after your remedial action because of some contributing factor that was not present at the time you tested. Plus isn't it nice to know what caused a problem so you don't do it again, rather than just masking it?  Also generally random actions like this don't help, and just make things worse, so attacking things incoherently is just a waste of time in a situation in which you're already probably not wanting to "invest" your time. This just increases frustration.

I use scientific method when I'm faced with a problem I can't nut out. Well a layperson's version of it anyhow. The process I use is basically this:

1. Make an observation, eg: the manifestation of the error on the screen, or the unexpected results, or whatever it is.
2. Form a hypothesis of what could be causing the error ("ah… that application-scoped variable has vanished").
3. Identify the manifestations / side-effects of the situation being hypothesised ("well if that variable has been blitzed, I'll be able to tell by looking in this other place").
4. Formulate an experiment to test the hypothesis, giving consideration to the bits identified in (3), as well as making sure the results of the experiment will conclusively demonstrate that the hypothesis is borne out. EG: simply restarting CF is not going to be a good experiment for testing a missing application scoped variable, as it doesn't actually identify what caused the problem in the first place. Basically you need measurable results (not just a nebulous change in state).
5. Perform the experiment, and aggregate the results & any side-effects noticed from the experiment, which might need to be tuned-out in subsequent round of experiment.
6. Draw a conclusion based on the results. Do the results of the experiment bear out the hypothesis? Quite possibly not, but they should help to finetune the next test of the hypothesis, or alter the hypothesis itself.
7. Rinse and repeat as necessary.

Now I'm not suggesting one needs to don a labcoat and deploy the pocket protectors to do all this (but hey, if that's your outfit already, all good ;-).  All it means is stop and give some thought to what you're doing, work out a coherent way to test the situation and approach things logically.

Most people I know don't do this, they just throw their hands up in despair (or in a jazz-esque sort of way) and post all their code to StackOverflow going "doesn't work".

And most people really struggle with step 4 there. Judging by the code people end up posting on the the forums, they don't generally have a concept of a portable reproduction case. If - for example - you are having an issue with a JDBC error coming back from a <cfquery> tag, the only things that are relevant are:

• the SQL statement being passed to the DB driver;
• any variables that contribute to the construction of said string;
• the values of any parameters being passed;
• the data source (and, by inference, which DB server one is using, eg: Oracle, MySQL etc);
• depending on the nature of the error, the schemas of any tables etc being queried;
• the error message
• what the expected results were ("this query is supposed to return [whatever]" or similar)

What is not relevant to any of this is:

• any code after the <cfquery> tag
• any code before the <cfquery> tag that don't contribute to the points above;
• never ever ever any "code" other than CFML. HTML is never going to be relevant to a CF error.

But what I often see posted to forums (or maybe in pastebin etc if the person is remotely sensible in that regard) is the contents of the entire file the error occurs in, including all mark-up, CSS, JS, and unrelated CFML. The immediate effect this has on me is to think:

• they've done bugger-all of their own troubleshooting if they haven't actually factored-out any of that from contributing to the situation;
• it's not occurred to them that by posting all that cruft, the person reading the issue is kinda forced to wade through it if only to find the bit they're talking about;
• if they can't be arsed doing any troubleshooting, why would they think I should be arsed either?

Now… back to my mention of a repro case. What one should do in this situation is pull the code that's causing the problem completely out of the context it's running in, mock the variables that it uses as inputs to perform its logic, decide what one would expect to get as a result, and then run the code. There will be three possible results of this:

1. If the code works, then one's assumptions as to what the problem is are actually incorrect.  It suggests that one of the inputs is not what one thought it is. That needs to be tracked down and then shift the repro case to that code to work out what the story is. This is forward progress because it has fine-tuned one's understanding of the issue.
2. If the code doesn't work in a different way from the initial error then one hasn't replicated the inputs properly. This needs to be fixed, and then the experiment repeated. In doing this, it will clarify what's going on and what's contributing to the problem. By the very nature that one's initial baseline expectation of the inputs and the results were off suggests that there's something missing from the analysis of the situation. This is a forward step in solving the problem.
3. If the code errors in exactly the same way as it was in its original context, then one has a repro case, and one has greatly reduced the factors that could be contributing to it. From here, it's generally pretty easy to work out what's wrong. Almost all issues that initially seemed "weird", "like a bug in ColdFusion", or "just don't make any sense" get solved at this point.

If one is still at stages 1-2, then one is not yet ready to post to a forum for help. Once one gets to stage 3 - and still hasn't cracked the problem - one's got a nice terse piece of code with known inputs and outputs which can be posted to a forum. At this point one will have a far better understanding of what's going on, can articulate the experimentation that has already been done and discarded as not contributing, and there's a small piece of code that someone trying to help can copy & paste down to their local system and run without having to horse around too much. It's also demonstrated that a reasonable amount of effort has already gone into trying to sort it out one's self, which will be a positive sign to anyone thinking of helping. Plus a lot of potential help suggestions will have already been tested and discarded, saving the people helping some time. It's an all-round win.

Also, if perchance the repro case demonstrates a ColdFusion bug, you've already got a repro case to send to Adobe. Excellent.

Describe the problem

A lot of this will have been covered already if the approach above has been taken. But what I mean here is too many people start a thread / question and basically say something along the lines of "I've got this code and it doesn't work. Why doesn't it work?"  The issue here is the person reading it doesn't know what constitutes "not working". It could mean there's an error. But one still doesn't know what sort of error (compile error, logic error, SQL error, etc); it could mean one was expecting ten rows back from the DB and is only getting one; it could mean the table is outputting ten rows by five columns when one wanted five rows of ten columns. The point is: one needs to identify what constitutes "not working". Seriously, this should be bloody obvious, but for some reason it is not.

Furthermore, if one has got an error, one needs to post the bloody error message. Do not describe the error (yes, people do this: "oh I got some error about the array being wrong").  And if there's code involved (OK, obviously with an error code will be involved! ;-), post the code and identify which line the error is saying is a problem.

Pay attention

Actually… let's back up. Before posting the error… read the bloody thing. So many questions I see are asking what the problem is where the error message is saying exactly what the problem is, and is identifying the precise line and column of the line the problem is at (usually this is with compile errors). Even if they're not that explicit, ColdFusion errors are generally very descriptive, and do pretty much identify what's gone wrong. I also encounter people who say "oh, I never understand that stuff" (seriously!), but when challenged and I say "OK, which word are you struggling with?" and ask "OK, even if you've not heard the term before: what do you think a 'complex object' [for example] might be?" they realise that it's just a case of never having bothered paying attention to the error message, rather than it being impenetrable in some way. I would say 80% of errors I get asked about can be solved by simply reading the error message.

There is no such thing as telepathy

People also have a tendency to assume that just because they know something (or are aware of something about their environment) that everyone else magically will. This is not the case. No-one else is privy to the internal mechinations of your mind, nor with they know your enviroment (or even your ColdFusion version, etc). One needs to make sure that any environment consideration or other peripheral factor needs to be actually articulated. People might be able to guess, but people probably actually can't. But either way: they shouldn't be made to guess. If nothing else it's a barrier to them helping you, which is counterproductive for you.  Consider this problem (this is actually something that I have had to deal with in the past):

SELECT        *
FROM        someTable
WHERE        someColumn = #someValue#
ORDER BY    anotherColumn
LIMIT        5

My DSN is MySQL, but this errors for some reason. If I run the same query in MySQL it works fine.

The problem isn't the filter or the table schema or anything like that. It's that this code wasn't a DB query, it was a QoQ on an earlier-fetched record set. The initial data came from MySQL, sure… but it didn't occur to the person that a QoQ is not run on the DB server, it's run on CF's own little SQL stub thing, and that doesn't support LIMIT.

Now the person should have just read the damned error message (and posted it), but at the very least they should have mentioned that this wasn't a DB query.

There is no such thing as telepathy (redux)

Another thing you need to do is to research the issue, once you've identified it. This means googling error messages, programming constructs you're struggling with, and anything else relevant. And if one still needs to ask for help (TBH, googling will solve 80% of problems: very few problems are unique), then part of your question should also detail what sort of research you've already done. Because if you don't mention it, then the first valid sugggestion one ought to offer you is "did you google it?". Some of you might think "well of course I will have researched it first, that goes without saying", but let me assure you: you're the good 'uns. Most people are bloody useless, and all they do is use StackOverflow and other forums as a kind of mechanical turk: to try to get other people to be their search engines. So let us know what you've already found. Also let us know what things you've found which might seem like a solution, but turned out not to be: this will save us making the same suggestion to you, and it's also useful information to fine-tune your issue.

Most errors are your fault

A lot of people posting questions start off from a fairly defensive position that whatever is going wrong, it's not their fault. They'll say "I don't know what's wrong, because my code works fine", or "I've found a bug in ColdFusion".  I'm sorry, but almost always this is not the case. 99% of the time… perhaps more… it's a problem with the code or the approach, or something like that. ColdFusion might have a number of bugs, but they're generally pretty esoteric these days, so the odds of someone who is having a problem with a listAppend expression having suddenly found a new bug in listAppend is rather small.

The problem I have with this way of thinking is that it's much easier to discover what a problem is if one starts with the mindset that it's one's self who's cocked-up, rather than someone else or Adobe. Firstly because it almost certainly is them, but secondly because is one is troubleshooting in a defensive way and going "well I know that works, so it can't be that", one's not going to spot the fact that actually it is that code that's got the problem. I think it's also a logical fallacy that "well my code works, so it can't be that, it must be something else", because the evidence that has lead one to decide something is wrong will be manifesting from a line in one's own code, so - really - even on first indications that's probably where the problem lies.

Approach this stuff with… um… an open mind (or just a neutral mind… just not a closed mind), and one will be in the best place mentally to find the problem.

Also one comes across as a bit of a cock if one starts asserting it's a bug in CF but it happens to be that they don't know the difference between listFind and listContains (or just didn't spot they'd used the wrong one). And it's best to not look like a cock if possible, yes? ;-)

---

Well that was a nice rant for a Friday just before Xmas, wasn't it?

I'm off to Ireland from tomorrow through until Dec 27 - I get to see my son for a dozen or so hours in that time… thankfully 2h of which is on Xmas Day - so I dunno how much attention this blog will get across that period. On one hand I'll have my laptop with me, but on the other hand finding internet connectivity is tricky. But I'm mostly stuck out in the middle of nowhere with little else to do, so perhaps wittering on will pass the time. Who knows?  I'll at least get part 3 of the regex stuff posted at some stage in the next coupla days.

In case this is it before you head off to do festive things that are more interesting than hanging on my every blog-written word, have a good break. And make sure to eat too much. And have a beer for me.

Merry Xmas.

--
Adam

Positive Communication from Adobe regarding ColdFusion: more thoughts

G'day (again):
I'm following the comment thread on the "ColdFusion: News, Initiatives and Updates from Adobe" blog post on the Adobe blog that got posted a few days ago. I offered my first tranche of feedback a coupla days ago, and here's my second lot.

These are replies to people's comments, and some general thoughts. I'm posting them here rather than there because this is too long for a comment cluttering-up someone else's blog. I'll cross reference this article over there too though. Also I want to get this discussion on the radar of my readers too, in case they're not aware of it, or have not thought/bothered to follow it.

I've worked my way down the comments, and commented / responded as I go. It's a bit stream-of-consciousness.

Regular expressions in CFML (part 2: concepts)

G'day:
This is part two of the series I started with the introduction article: "Regular Expressions in ColdFusion (part 1: overview)". Initially I set out to only write one article, but by the time it was over 8000 words long, I figured I should split it up and serialise it otherwise no-one would be brave enough to read the whole thing.  If you see references in the text to "see above" or "see below", it might refer to something in one of the other articles. I'll try to find them all and replace with links, but no-doubt I'll miss some.

Concepts / components of a regular expression

A regular expression is built out of all those seemingly random sequences of punctuation characters. Taken en masse, that's quite impenetrable, and it's good to take a step back to consider the various notions / components / building blocks that are important to regexes. This is just a narrative / conceptual discussion, rather than delving into syntax, just for the moment. Knowing about the concepts is more important as the minutiae of the syntax, and once we have a handle on the concepts, the synactical vagaries will make more sense, and the expressions themselves will seem less daunting. In theory ;-)

When functions do too much, and how to get them to do more

G'day:
After soliciting more UDFs for CFLib a while ago, I've been dead slack at processing the inbound queue, and fixing some bugs people have found. Sorry about that. I started playing catch-up at lunchtime today: you might have noticed a coupla bugfixes bubbling through on Twitter if you follow the @cfbloggers feed.

Regular expressions in CFML (part 1: overview)

G'day:

Before I start
This started off being a single article, but it ended up way too long. And by the time I've come to be divvying it up, I'm thoroughly fed-up with it, so I'm not going to do the usual book-ending of each "sub-article", I'm just gonna fairly arbitrarily cut the thing into sections, and post each section as a new article. So it's gonna be best to start at the beginning and work through to the end, as the subsequent articles might not be fully contextualised in and of themselves. I'm also gonna serialise the thing over a few days, rather than releasing them all at once. Anyway... hold on to yer hat... regular expressions...

I've been mulling-over writing this article since I first started this blog. On one hand I'm fairly good with regular expressions, and a lot of ColdFusion developers (most of the ones I have encountered, anyhow) are not. So there's potential for a teaching exercise there. On the other hand Ben Nadel had banged-on so much about regexes so much in the past one might think there's little else left say on the matter.

Positive Communication from Adobe regarding ColdFusion

G'day:
In a break from the perceived doom & gloom I have been seeing recently regarding CFML - this blog, Sean's blog, Andy's blog (Andy's gripe is specifically about the ColdFusion installers not working on the current versions of Windows), the Fusion Authority blog etc, some  stuff from the Railo community (which seems a bit counterproductive to their cause, but it's only an element of the lunatic fringe that engage in this), and various series' of sound-bites on Twitter - Adobe published a very positive-sounding article on their official ColdFusion blog yesterday. It should come as no surprise that Adobe are sounding positive about their product, but it's really not something we hear too much of too often (Rakshith, take note ;-).

One might think that the article was all just self-promotion & marketing spiel, but this one actually had a bit of meat to it, which was refreshing.

Am I right to think this is stupid?

G'day:
This was brought to my attention via a thread on the Adobe forums in which someone was messing around with "closure" functions being used as callbacks.  One of the statements they made was:

The only thing I observed: a closure does not seem to be a function, because isCustomFuntion (..) returns false. Maybe this should be changed, I dunno.

My reaction to that was "[cough]bullshit", but I decided I better not back my instinct, I'd better make sure I was right first.  But I wasn't right. Typically, the online docs for isCustomFunction() are not much help here:

The IsCustomFunction function returns True for any function that can be called as a custom function, including functions defined using CFScript function declarations and cffunction tags, and functions that are ColdFusion component methods. For CFC methods, first instantiate the component.

On first take - other than having moderately curious wording -  that seems to suggest what is logical: if I create a function with function / cffunction etc, and pass it to isCustomFunction(), I'll get a TRUE result. If what I pass it is anything else (eg: just a string, or a struct or something), I'll get a FALSE.  However this is not the case.

Wanting script to work like tags (#1 in a series of "fool's errands")

G'day:
Ever since ColdFusion 9 implemented a jerry-built¹ way of making DB calls in CFScript via Query.cfc, people have been observing/complaining/hand-wringing that the way one passes the SQL string from the calling code to JDBC via CFML is much more elegant with the CFQUERY tag than it is with using Query.cfc. In case  the situation if not clear, here's an example:

Constants for CFML

G'day:

Updated 2024-08-30

Reworded to avoid my misuse of the word "singleton" which I was using to mean "an object that is created once and reused", which is not a singleton. A singleton is about implementation, not usage. This was pointed out to me by John Whish of the CFML community, during a conversation we were having about misuse of that term.

This one is just an idea I had for ColdFusion 11 (or Railo... just "for CFML" really). Well it's not an idea that's particular to me, nor is it a new one. Or an earth-shattering one. Or one that will sell any licences in and of itself. It would be handy though.

CFML has no notion of named constants, EG:

const PI = 3; // near enough ;-)

Whilst one can created variables, not all values are supposed to be variable. For example π doesn't change: it's not a variable. It doesn't vary.

Forgot to say

G'day:
OK, I often say "this'll be a quick one", and then waffle on for a coupla thousand words. Not this time: it'll be quick.

One thing I forgot to mention in the "I love being wrong" article I posted a few hours ago was how I determined that the form scope was indeed being deleted and reconstructed every request, not simply being cleared (because as I mentioned: it's being both cleared and deleted, which seems logically tautological, if you see what I mean).

I love being wrong

G'day:
That's not sarcasm, I actually do rather like being wrong about stuff: it's a great vector for learning new things and improving one's knowledge. Provided one doesn't get defensive about being wrong (which if just daft), and does endeavour to understand how one was wrong, and do something about it.

Anyway, enough airy-fairy philosophising. What was I wrong about?

The form scope.

Survey Results: where to focus Adobe's efforts to improve CFML's CFScript coverage

G'day:
Thanks to a coupla people fwding my Twitter status updates asking for participation, and I guess repeated nagging from myself; on Friday last week I finally hit my target of 50 responses.  I've closed that survey now.

The results were fairly predictable, I guess: no-one's interested in UI-ish things (form, layout & UI widgets) being availed in CFScript, and a bit of a mix in between.  Basically people thought "internal" type stuff, or integration with some external systems warranted inclusion in CFScript, but were a bit "meh" about it other than that.

What's up with OpenBD?

G'day
This is just a quick one.

I found myself - yet again - typing into one of my articles (an update to yesterday's one which discussed CFML's date datatypes) something to this effect "but the code didn't work on OpenBD, so I didn't bother testing it".

What you see is not necessarily what you get

G'day
This is another case of me not having enough space on Stack Overflow to articulate myself properly, so I'm creating a blog article and will cross reference my answer to here. With enough of a summary on S/O to try to avoid snippy comments from the self-appointed sheriffs.