Ballot stuffing: vote for Railo

G'day:
No, I'm really not advocating ballot-stuffing. However someone's creating a poll to get Railo added to Bitnami's stack. This would improve Railo and CFML's market penetration, so it has to be a good thing. And the sort of thing the vendor's themselves ought to be promoting.

Even if you're not a Railo user or advocate, and are staunchly a ColdFusion fanboi (you know who you are), this must be good for CFML.

Go vote. Here: https://bitnami.com/stack/railo.

--
Adam

PHP: looking at some interesting "unexpected" behaviour with references

G'day:
A week or so ago I was fascinated by this Stack Overflow question: "How to changing value in $array2 without referring $array1?". It offers this code:

// baseline.php

$array1 = array(1,20);
$x = &$array1[1];
$array2 = $array1;
$array2[1] = 22;
print_r($array1[1]); // Output is 22

And this result:

22

In PHP, as the = operator makes a copy of the variable being assigned, so one (and when I say "one", I mean "the person asking the question, and myself as well") might be surprised to see the answer is "22", rather expecting it to be "20". Surely $array1[1] is discrete from $array2[1], and $array1[1] should not be impacted by the change to $array2[1]. $x is not a macguffin in this: remove that line, and things behave "as expected". How is making $x - a reference to $array1[1] - somehow intertwined with $array2??

PHP: significant oversight in the implementation of array_reduce() (and I find the PHP bugbase...)

G'day:
I was fishing around in Stack Overflow this morning for a quick PHP exercise to do before getting out of bed (there's some imagery for you), seeking coffee, and getting on with the day.

I found this one: "Explode my Array, remove dash from key, then Implode it back together". It already had an accepted answer which involved just a coupla foreach() loops, but I thought I could come up with something more descriptive using array_reduce(). And I thought I'd post it anyway as an alternative approach.

However I ran into a problem.

Looking at PHP's OOP from a CFMLer's perspective: object serialisation

G'day:
This continues my series which is thusfar:

• Looking at PHP's OOP from a CFMLer's perspective: classes, objects, properties
• Looking at PHP's OOP from a CFMLer's perspective: inheritance, static & abstract, interfaces
• Looking at PHP's OOP from a CFMLer's perspective: traits
• Looking at PHP's OOP from a CFMLer's perspective: namespaces
• Looking at PHP's OOP from a CFMLer's perspective: overloading (which is not what you'd assume it is)

The next section in the PHP OO docs is actually "Magic Methods" (oh please), but two of these are __sleep() and __wakeup(), and these relate to object serialisation, so I decided to have a look at how this works, and __sleep() and __wakeup() at the same time.

PHP: another generator example: primes

G'day:
Duncan has mused me again. He's reworking his Project Euler exercises that he'd previously done in CFML, and is now implementing in PHP. In yesterday's exercise he was looking at prime numbers: "Project Euler: problem 7 (PHP)". I thought there was scope for another exercise in using PHP generators in this for me (see previous: "PHP: generators").

Adobe: stop closing ColdFusion bugs you haven't dealt with

G'day:
I've had a frickin' gutsful of Adobe's amateurish and disrespectful approach to dealing with bugs in the bug tracker. I spotted yet another "closed, not enough time" issue today. One which hit me back in 2011. It was first raised in 2009. Five years ago. It first cropped up in CFMX7. It's not a complicated one, it's just that the seem to have a glitch in working with leap years, for some date calculations. "Bug 82249:(Watson Migration Closure)Datediff function does not calculate differences correctly".

This has gotta stop, Adobe.

I checked the bugbase to see how many issues had been closed with "not enough time".

349.

Dating back to 2005.

These are all bugs that have impacted paying clients sufficiently for them to bring them to Adobe's attention. And Adobe's reaction is to just go "oh well... [shrug]... [clicks the 'Close' button]".

This is unacceptable.

PHP: more boolean / null confusion (and perhaps not entirely on my part)

G'day:
I'm so very confused.

OK, there's a precedent contradicting my PHP "Null" gripe from the other day

G'day:
What would I do without my guardian angel Sean? ;-)

Over the weekend I wrote an article "PHP: a fractal of [etc]... yeah, I'm now getting where you're coming from", which I - in passing - derided PHP's choice of null being a boolean false.

PHP: a fractal of [etc]... yeah, I'm now getting where you're coming from

G'day:
Null.

PHP: iterators

G'day:
I'm now at the pub (see "PHP: generators"), and have just started my third Guinness. I've not yet worked out what this does to my writing style, so that could be a good or a bad thing. [shrug]: it's my blog.

Anyway, In the article linked to above, I talked about generators, and in the process I mentioned PHP has the notion of iterators, but didn't really have a close look at what those are in the context of PHP. Obviously we all know what an iterator is, but I figured part of my learning process had better be to get a good handle on PHP's implementation.

PHP: generators

G'day:
Duncan's my muse today. Like me, my mate Duncan has recently moved from our defunct CFML team to the PHP team. And like me, Dunc now needs to learn PHP. He's logging his progress as well, and if this sort of thing interests you (following our progress), then maybe keep an eye on what he's doing too.

Answering my first PHP question on Stack Overflow

G'day:
It's really quite interesting. With any CFML question someone might ask me, I am brimming with confidence (or bravado, perhaps), am self-assured, and have no problem either backing myself to be correct, or happy to say "dunno, but I'll find out". I've decided I had better start answering PHP questions on Stack Overflow, as answering questions is a really good way to learn stuff. Especially if one doesn't know the answer to start with.

I would actually love to see your Railo 5.x wishlist...

G'day:
That was a comment from Gert against the article "ColdFusion 12" article.

Fair enough.

I started writing my response as a comment, but whilst typing it my interest was piqued regarding one of my own thought processes. It would just never occur to me to write an article about a wishlist for Railo. And I don't know why. I prefer the product to ColdFusion (which is easy: it's just better, as are the company & personnel behind it), but this sort of article doesn't seem necessary to me, in a Railo context. I suppose it's because getting Adobe to do anything sensible with CFML is a hard-fought battle, and left to their own devices they either mess shit up, or come up with stuff like <cfclient>. So they need strong direction / coercion from the community. Conversely with Railo, they already have a better idea of what a CFML developer needs, and often come up with the goods before it occurs to anyone to ask for it. Or if one does make a good case on either the Google Group or Jira, they just crack on with it and do it.

So it's not neglect of Railo that doesn't have me writing "My Wishlist for Railo 5.x" etc. It's just never been necessary.

Equally in the back of my mind I know the Railo guys will take on board anything anyone suggests for ColdFusion, and either implement it first, or go "nah, not a good fit for Railo". So I suppose my article would better be titled "CFML-next Wishlist".

Still, Gert asked, so Gert gets. Here's what I said in the comment, before promoting it to being an article:

Rendering a GitHub file in this blog

G'day:
A few days back I released that CFScript documentation effort, which at the time was just done inline as a blog article. I had not decided how best to home it so it could be found. I thought about putting it on GitHub, but in my experience Google is lousy at finding stuff on GitHub. As unimportant as the adamcameron.me domain is in the bigger scheme of things, I seem to rank quite well when it comes to CFML topics (ed: that CFScript page bloody doesn't, mate), so I figured putting it here would be a good first step.

CFScript docs now on GitHub

G'day:
That CFScript documentation thing I released the other day ("Documentation for CFScript") is now on Github @ "CFScript documentation".

Currently it's a duplicate of the stuff on the blog article, but the GitHub one will be treated as the master copy from now on. I am in the process of simply embedding that back into the original article so that the article is always current. I should have that done in the next day or so.

PHP: references

G'day:
Yeah, it's been a busy day today. But I'm quite pleased with the PHP stuff I've learned. This is another quick one (OK, I'll stipulate now: a lot of these PHP ones will be short, so I'll stop saying that), and harkens back to something I talked about re CFML back in 2012: "Complex data-types in CF, and how they're not copied by reference".

PHP has a concrete and code-controllable notion of references; not just something that happens under the hood like in CFML.

PHP equivalence: onMissingMethod()

G'day:
Whilst looking at overloading in PHP before ("Looking at PHP's OOP from a CFMLer's perspective: overloading (which is not what you'd assume it is)"), I thought I might need to write an equivalent on onMissingMethod(), to catch instances of me calling... methods which I expected not to exist. I didn't need to because PHP works differently form how I expected it to, but it piqued my interest so I've just looked up how this is done. It's easy.

PHP equivalence: getFunctionCalledName()

G'day:
I touched on this in the last article: "Looking at PHP's OOP from a CFMLer's perspective: overloading (which is not what you'd assume it is)". PHP has a magic constant __FUNCTION__ which returns the name of the function being called. I claimed it's kinda like getFunctionCalledName() in CFML. But not quite. Let's have a look.

(This will be a pretty short article, I think).

Looking at PHP's OOP from a CFMLer's perspective: overloading (which is not what you'd assume it is)

G'day:
This is the fifth part of a series. The first four parts are here:

• Looking at PHP's OOP from a CFMLer's perspective: classes, objects, properties
• Looking at PHP's OOP from a CFMLer's perspective: inheritance, static & abstract, interfaces
• Looking at PHP's OOP from a CFMLer's perspective: traits
• Looking at PHP's OOP from a CFMLer's perspective: namespaces

Today I'm looking quickly at a PHP concept called "overloading". Which has nothing to do with the usual OO concept of "overloading", either in the sense of same-named methods with different signatures, or operator overloading. In fact I seriously dunno why they called this construct overloading at all.

Documentation for CFScript

G'day:
I am going to attempt to document all of CFScript, as a resource for people migrating from old-school tag-based code to script-based code. The reason I am doing this is because neither ColdFusion nor Railo provide much (or in the case of Railo: any) useful documentation of CFScript.

This is not a document for converting tags to script. It is not written from a point of view of "if you use <cfsometag> then you need to instead use [some script construct]". It simply documents CFScript. It does - however - set out how to perform all CFML functionality using CFScript. It is also not an exercise in teaching CFML (or at least the script part). It assumes you know what you're doing, and is purely a reference. I am contemplating another article / series of articles which teach CFML correctly (the various resources that exist to do this all take the wrong approach, and are a barrier to CFML uptake, IMO). [ed: obviously that plan has been permanently shelved now].

Also there won't be a great narrative structure to this article. It's just a loosely-structured series of sections covering coding topics.

I assume Railo 4.2 or ColdFusion 11, except where stated.

Update:

I have ported this stuff to GitHub. See "CFScript docs now on GitHub". The version below is a mirror of that. Given it's on GitHub, if you see any problems or want to augment these docs: DIY, and send me a pull request. Cheers.

CFML: weirdness with properties

G'day:
Sigh... didn't take long for me to be writing CFML again. My excuse is this started out being comparison code for a PHP article, but I've run into some issues.

Come on Adobe: bring Anit to CFSummit

G'day:
OK ColdFusion community: time to voice your will again.

Brad started this conversation off:

Hey @anitkumar85, will you be at CF Summit this year? You're one of the most visible on the CF team, so I'd love to meet you cc/ @ColdFusion
— Brad Wood (@bdw429s) September 12, 2014

And the notion needs support: currently Anit is not attending CFSummit, and that's not really on.

Looking at PHP's OOP from a CFMLer's perspective: namespaces

G'day:
This is the fourth part of a series. The first three parts are here:

• Looking at PHP's OOP from a CFMLer's perspective: classes, objects, properties
• Looking at PHP's OOP from a CFMLer's perspective: inheritance, static & abstract, interfaces
• Looking at PHP's OOP from a CFMLer's perspective: traits

Today I'm looking quickly at namespaces.

RSS URLs

G'day:
A couple of the RSS URLs for this thing have changed. The correct ones are in the box to the right, and as follows:

• Default feed
• Last ten articles (full)
• Last ten articles (summary)

I think the default one has stayed the same, but the "last ten" ones have changed, due to domain name change.

--
Adam

Sally Field

G'day:
After y/day's article "So long, and thanks for all the CF", a lot of people have been saying a lot of very flattering things. I've decided I'd sound even more like a wanker than usual if I thanked everyone individually, so I'll just say "hey, thanks for the kind words" once, now. That was it just there.

I'm also fascinated no-one has (yet) said "good riddance" or some such. I figured I'd get a bit of that. Perhaps ppl are keeping their thoughts to themselves.

A couple of updates.

I tried to switch off the @cfmlNotifier feed, but for some reason it's still broadcasting?! This is really odd because generally speaking I need to restart it every day anyhow. Weird. On that: someone's picked up the reins on that project, has grabbed my code and is trying to work out what drugs I was on when I wrote it as we speak. They hope to have it up and running shortly (they mentioned 24h, but no pressure ;-).

In one of my blog comments someone indicated I seemed to be not only leaving the community, but also slamming doors behind me: what with the renaming of the blog, the new subdomain (just "blog" rather than "blog"), unsubscribing from mailing lists etc. I can assure you I leave the community with no sense of malice at all. The simple fact is I have been focusing on CFML because I have been paid to... now I'm not being paid to: I'm not going to focus on it. My after-hours hobby is computer programming, not necessarily computer programming in CFML. I take what I do seriously, and I believe any dev who is to be taken seriously ought to be doing dev in their spare time as well as 9-5. Accordingly when I take my job as a CFML developer seriously, I look under rocks, open the cans (of worms), and stir the pot. But I simply won't be doing that with CFML any more, because I won't be using CFML any more. After I get up to speed with PHP, I'll probably do it to PHP instead. As you might have already noticed ("PHP: how does PHP deal with same-named form values? [shudder]", "PHP's error "handling". Oh dear"), I've already been calling it into question.

The "rebrand" is just - as Dom said in his response to that comment - just tech-neutralising it all, and being more representative of the content, going forward. I'm not really going to be writing about CFML any more (there's one more article in the pipeline), so it would be stupid for this thing to stick with its association to CFML. It's not like I'm unpersoning all the articles, and changing the historic "CFML" references to "PHP" or anything!

Also bear in mind I have already rebranded once. This used to be "Adam Cameron's ColdFusion Blog", but the more I started working with Railo, the less it seemed sensible to describe it as a ColdFusion blog, so changed it to "CFML".

So long, and thanks for all the CF

G'day:
The rumours I've been seeding recently have turned out to be true. Today I got confirmation that I am leaving the CFML community and joining the PHP one.

CFScript 2.0 follow-up

G'day:
A few days ago I put up this article: "CFScript 2.0?". At that juncture I was just soliciting input from the community. It's worth reading the comments if you're not up to speed with them. Especially from a Railo perspective as Micha, the chief engineer, offers his thoughts. It's a pity we don't get similar input from Rupesh on this, from a ColdFusion perspective.

I think it's been favourable enough to warrant enhancement requests to the vendors, which I have now raised: RAILO-3199; ColdFusion: 3822362.

Go have a vote (one way or the other! Even if you disagree, your input is valuable), and put your oar in and let your vendors know what you want them to do.

Cheers.

--
Adam

Update regarding irritation: cheers Rakshith

G'day:
Y/day I got all ranty with this: "Please indicate your irritation @ the ColdFusion Team".

A bunch of people joined in the irritation (that sounds vaguely NSFW, I know), and fortunately Adobe have fed back:

@dacCfml @AdamTuttle @adobeCare @ColdFusion This issue will be reopened and evaluated. #ColdFusion
— Rakshith Naresh (@rakshithn) September 10, 2014

Adam made a good follow-up point, and Rakshith responded positively to that too:

@AdamTuttle @dacCfml @adobeCare That should have been the initial response itself. Something for us correct going forward.
— Rakshith Naresh (@rakshithn) September 10, 2014

This is all positive. I thanked him on Twitter, but I just wanted to say thanks here too.

Good man, Rakshith: thanks.

--
Adam

Looking at PHP's OOP from a CFMLer's perspective: traits

G'day:
As the title says, this is the third part of a series. The first two parts are here:

• Looking at PHP's OOP from a CFMLer's perspective: classes, objects, properties
• Looking at PHP's OOP from a CFMLer's perspective: inheritance, static & abstract, interfaces

I suspect this will be the last part on this topic, but don't hold me to that just yet. Let's see how it goes (update: no, not by a long march... I'm writing part 4 now, and there'll be more after that).

Basically I'm working my way down the topics on the "Classes and Objects" page of the PHP reference, and getting myself up to speed with how PHP does it's OO. And documenting my observations as I go.

Please indicate your irritation @ the ColdFusion Team

G'day:
They've gone and done it again, as apporproately described by Adam Tuttle:

.@dacCfml here's a giant pile of @adobe bollocks: https://t.co/1bm94AJlHI http://t.co/lx6ZrucqUi
— [object Object] (@AdamTuttle) September 9, 2014

PHP: how does PHP deal with same-named form values? [shudder]

G'day:
I seriously hope I'm wrong here, but it seems to me that PHP's default "handling" of multiple same-named form fields is... to ignore all bar the last one. That's not to say the values aren't still accessible for one to deal with via bespoke code, but... come on PHP. Really?

OK, so CFCamp 2014 after all

G'day:
As you may or may not know, I'm almost certainly going to be leaving the CFML world shortly. I should have clarity on that in a few weeks, and will give you the details then.

Last year Mike Hnat - organiser of CFCamp - very kindly covered my costs to go to CFCamp 2013, and I had a really excellent time (see various articles on the topic here: "CFCamp"), and promised myself and him I'd be back in 2014. And planned to do it on my own dime this time.

Enhancing block syntax in CFML

G'day:
This is not an article per-se, but just a heads-up to go have a read of something Rory (I dunno Rory beyond his name on the forum post) has raised on the Railo Google Group: "I actually like tags in script". I think this is worth a read, and worth people putting their oar in.

And, hey, listen: even if you are a staunch ColdFusion-only person, it's worth reading and participating in the conversation, as it's a general CFML topic, and what Railo implements generally leads the way for where Adobe's CFML goes (except when Adobe balls it up, which, admittedly, is frequently). The Railo Google Group is probably the best place to discuss CFML stuff, in my opinion.

So, anyway, go have a read, a think, and put your thoughts down.

I'm still formulating my position, and when I flesh it out I'll post it both there and here. Obviously I don't agree with everything he says (esp. given its basis is in part specifically disagreeing with things I've had said in the past), but I don't disagree as much as Rory might think I do.

I'm in Ireland over the weekend, so that gives me plenty of time to think about stuff (at the Salt House, pint in hand), so I should come up with something at some stage soon.

Righto.

--
Adam

212... 0

G'day:
I've been keeping an eye on how many untriaged ColdFusion bugs there are:

• 212 untriaged ColdFusion 10 bugs
• Follow-up to "212 untriaged ColdFusion 10 bugs"
• Bug watch: 212206 untriaged ColdFusion 10 bugs
• Good work Adobe ColdFusion Team!

Help provide Adobe with more info, pls

G'day:
Hey, Adobe are struggling to replicate the issue I detail in 'Have found some evidence for that "There was an error accessing this page. Check logs for more details." issue in CFAdmin', and raised as ticket 3810459. Which Adobe have closed as "works OK on my machine".

This is the situation in which CFAdmin will sometimes present this error when trying to make settings changes:

If you have experienced this, could you pls chime in on 3810459? Even if you haven't solved it, providing Adobe more info would be helpful. Plus would help them realise it's a real issue that impacts a bunch of people, not just me and the other bod who has commented.

Thanks.

--
Adam

Wrong wrong wrong, Cameron is wrong

G'day:
Adam Tuttle and I were talking on IRC about some of my code today - in the context of closure - and I brashly asserted the code might implement closure, but it didn't actually use it, so it was a bad example of closure in action (like, admittedly, almost all examples people use when demonstrating it).  I further posited I could simply use declared functions instead of inline function expressions and the code would still work, thus demonstrating my case.

TL;DR: I was wrong about that. But it doesn't sit entirely well with me, so here's the code.

Repro of structCopy() bug

G'day:
I could put this in a gist or just post the code directly, but it gives me something to write about today. Be wary of structCopy(). There's a bug been raised about it not working on ColdFusion scopes, which Adobe don't quite seem to be able to understand. The ticket is 3815793.

Looking at PHP's OOP from a CFMLer's perspective: inheritance, static & abstract, interfaces

G'day:
So I continue my battle through PHP's OO implementation. See "Looking at PHP's OOP from a CFMLer's perspective: classes, objects, properties" for the first bit of this.

CFScript 2.0?

G'day:
You will be used to me bleating about how Adobe have messed up a chunk of their CFScript implementation in ColdFusion 11 (and ColdFusion 9 for that matter too), eg: last week's "Example of the thoughtlessness of a generic tag to CFScript solution", plus "ColdFusion 11: cfloop in CFScript very broken"; plus some suggested fixes: "How about this for savecontent?" and "Another suggested tweak to CFScript: thread". But one of my readers has mentioned in passing a good approach to solving it, and revisiting all the things that are wrong with CFScript.