Sunday, 28 September 2014

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

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:


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??

Saturday, 27 September 2014

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

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.

Friday, 26 September 2014

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

This continues my series which is thusfar:

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

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").

Tuesday, 23 September 2014

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

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".


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)

I'm so very confused.

OK, there's a precedent contradicting my PHP "Null" gripe from the other 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.