Showing posts with label grief. Show all posts
Showing posts with label grief. Show all posts

Wednesday, April 3, 2013

More PHP grief

I'm sorry, but I just have to link to this article:
I'm sorry, but PHP sucks
For example, from Point 3:
(string)"false" == (int)0> is true

Look, if you use PHP regularly, it's worth reading the good and the bad to better understand your tool. And in any case, he does finish with this:

That said, I am a huge advocate for choosing "the right tool for the job" and that, or course, means that you might want to choose PHP under the right circumstances. I'll give you a few examples:
- You have found the ideal framework or base for your software and it's written in PHP
- You already have a huge investment in PHP technology
- Your time-constraints do not allow you to learn something else

Tuesday, March 12, 2013

PHP grief

Speaking of grief in PHP, I've been starting to code seriously in PHP for all of a few months now, and I'm learning a lot as I go, but man, the pain, the grief PHP inflicts upon the unwary

Having read The PHP Singularity - and then STILL deciding to go that path, I thought I was well prepared for what lay ahead. How wrong I was! PHP has an uncanny knack of kicking you in the bejezel when you least expect it.

For example. I learnt that all arrays in PHP are associative. Ok, I can deal with that. array[0] is really just array["0"] or something like that. It's really quite flexible. So I was a little disturbed when I went looking for how to determine if a given array is associative or not. I mean, it can't be that hard right!? (I've got to stop saying that!) It wasn't just that there was no "correct" way to determine the answer. It wasn't just that every thread I stumbled across that discussed it was suggesting bizarre and crazy ways to determine the answer. I mean, having much Perl experience I'm familiar with the "many ways to skin a cat" paradigm. But all the answers I found just seemed so... ugly!

Look, I'm not the worlds greatest programmer. Far from it. But still, I like my solutions to be both simple and stylish, if I can help it. That PHP has a built-in function for sooo many things, but not this... Well, what else to expect from a committee-designed weakly-typed language I guess. If I don't like it, I can always bugger off I suppose. *sigh*

In the end I settled on this:

function isAssoc($array) {
        return array_values($array) === $array ? FALSE : TRUE;
}

Also, what's with these damn error messages - or lack thereof! It's bad enough that there's no way to enforce type checking and variable declaration (No, really, I want to declare ALL my variables before I use them. Honest!) similar to Perl's "use strict". But how hard does PHP make you work just to see ANY error messages!? And even then on certain versions (not that old, I swear) php -l wouldn't even tell me what line number my error was on, simply saying:

syntax error in file

Syntax error somewhere in your file. Good luck with that. Gee, thanks PHP.

Another thing that really bugs me is the way PHP will sometimes tell me the variable I'm trying to use has not been initialised before use, but at othertimes wont. What is with that!? Ok. This might only apply to (slightly) older versions of PHP, but unfortunately our PHP server at work cannot be upgraded for reason too complicated to explain here :(

On the other hand, PHP gets upset if I try to apply the ++ operator to an array, even if I've initialised the array as empty.

BREAKING NEWS: I've discovered the array_fill() function. So now I can initialise my arrays with:

$a = array_fill($start, $size, $initial_value);
and dodge all those nasty "undefined offset" errors which so many PHP programmers don't seem to mind scattered all through their logs.

Array Insert Order

Ok. Associate arrays. Great. Index arrays. Still work just fine. But arrays that remember the order of insertion? Please, does that has to be built-in to the language?? For the love of programming, why? So:

$a[5] = 'five';
$a[1] = 'one';
$a[8] = 'eight';
$a[2] = 'two;

echo implode(',', $a);
will print:
five, one, eight, two

IS THAT REALLY NECESSARY??

Ok. Before I learnt to use array_fill() - which inserts my initial values in order anyway - I found that I could get my elements back into index-order with a ksort(). Eg. With the example above, if, before the "echo" statement, I add:

ksort($a);
I will then get my elements printed in the expected order: one, two, five, eight.

But of course I wont need to as I'll be using array_fill() so as to avoid any "undefined offset" errors.

Monday, March 11, 2013

parse_ini_file grief

I know that different versions of php can vary greatly, but this is ridiculous and exposes just how miserable it can be when trying to debug Php code.

I had parse_ini_file working perfectly well developing on my desktop mac. Not too difficult a task. Then I tried to deploy to the server and got this error:
Warning: file_get_contents('http://localhost/server-status'): failed to open stream: No such file or directory in /.../apachemon.php on line 183
Now strike me grievously but how am I supposed to spot the mistake here!? (hint: I am 100% certain the resource at "http://localhost/server-status" does exist) Did you spot it? At the time I grumbled and prodded and poked and extracted code segments attempting to test them in isolation.

And eventually, I figured it out.

Now I could be wrong on this, but I don't think I'm an idiot! I've debugged my fair share of code. But even when I structure my code well, implement a decent Logger, and test as best I know how, Php still has a myriad of ways to kick me in the butt.

Did you spot the bug yet?

On my desktop I'm running PHP 5.3.15 and on the server it's PHP 5.2.6. Is that such a big difference?

Now I think I'm actually starting to enjoy coding in php. At least, when it works! But for now, I think I know what my Php debugging catch-cry is:

"Good luck with that!"

Oh, and the bug, just in case you didn't spot it. Or should I say, the "bug":
I used single quotes but apparently it wanted double quotes