PHP variables, strings, and curly braces

For the last couple of days we had a number arguments at work about what is the best way to surround a complex PHP variable inside a double-quoted string.  More specifically, should the sigil ($, dollar sign) be on the inside of the braces or on the outside.  Consider an example:

# my way
echo "Result: ${blah['something']}\n";
# the highway
echo "Result: {$blah['something']}\n";

While considering a number of examples, there seems to be no difference – both ways work.  We’d still need to pick one for consistency reasons though.  And I, as an ex-Perl programmer, was suggesting that we should use the dollar sign on the outside of the expression.  This how I remember it being in Perl (and PHP originated from Perl) .  This is how I am used to it.  And this is how makes most sense to me – a dollar sign immediately warns the programmer that the variable is ahead.

However, after consulting PHP documentation, I was proved wrong.  It is said that both ways often work, but it is much safer to use the dollar sign on the inside.  The manual page even provides a few examples where the dollar on the outside won’t work (such in case with objects).

While this is just a small thing to know and get used to, it still looks annoying to me.

Programming religions

I’m slowly catching up with the news stream and all the jokes of the last few weeks.  “If programming languages were religions” is a nice one.  Here is PHP, which I spent the most time with now:

PHP would be Cafeteria Christianity – Fights with Java for the web market. It draws a few concepts from C and Java, but only those that it really likes. Maybe it’s not as coherent as other languages, but at least it leaves you with much more freedom and ostensibly keeps the core idea of the whole thing. Also, the whole concept of “goto hell” was abandoned.

And here is Perl, which is my favourite programming language so far:

Perl would be Voodoo – An incomprehensible series of arcane incantations that involve the blood of goats and permanently corrupt your soul. Often used when your boss requires you to do an urgent task at 21:00 on friday night.

Check the rest of them for fun and profit.

Perl vs. PHP : variable scoping

I’ve mentioned quite a few times that I am a big fan of Perl programming languge.  However, most of my programming time these days is spent in PHP.  The languages are often similar, with PHP having its roots in Perl, and Perl being such a influence in the world of programming languages.  This similarity is often very helpful.  However there are a few difference, some of which are obvious and others are not.

One such difference that I came up recently (in someone else’s code though), was about variable scoping.  Consider an example in Perl:

#!/usr/bin/perl -w
use strict;
my @values = qw(foo bar hello world);
foreach my $value (@values) {
    print "Inside loop value = $value\n";
}
print "Outside loop value = $value\n";

The above script will generate a compilation error due to undefined variable $value.  The one outside the loop.

A very similar code in PHP though:

#!/usr/bin/php
<?php
$values = array('foo','bar','hello','world');
foreach ($values as $value) {
    print "Inside loop value = $value\n";
}
print "Outside loop value = $value\n";
?>

Will output the following:

Inside loop value = foo
Inside loop value = bar
Inside loop value = hello
Inside loop value = world
Outside loop value = world

In Perl, variable $value is scoped inside the loop.  Once the execution is out of the loop, there is no such thing as $value anymore, hence the compilation error (due to the use of strict and warnings).  In PHP, $value is in global scope, so the last value “world” is carried further down the road.  In case you reuse variable names in different places of your program, counting on scope to be different, you might get some really interesting and totally unexpected results.  And they won’t be too easy to track down too.  Be warned.

PHP 6 – hopefully not the end of the road

I’ve heard plenty of positive buzz about PHP 6 in the last few weeks.  Yes, it’s coming out.  Yes, it brings quite a few improvements, including better Unicode support, better security, and more help for larger projects through namespaces.  However, I hope that it won’t be the last PHP release, since there are so many other things that need fixing.

Here is a good overview, as compared to the best programming language ever – Perl.  But this probably reminds you of a famous Euro-English joke, no?   But I do miss sigils and proper hashes.  I’d love to see better memory management when programming objects.  I’d love to see improved database interfaces with prepared statements and database abstraction layer.  I would really welcome a cleanup in function names and return values. I … I … I … I hope that PHP 6 is not the end of the road, and that PHP 7, PHP 8, and PHP 9 will follow.

Happy Birthday, Perl!

My favorite (so far) programming language has been born 20 years ago.   It’s been loved and hated.  It’s been praised and damned.  It’s been complimented and criticized.  But all that doesn’t matter.  What matters is that it has been helping people all over the world to solve problems.  Tricky, boring, annoying problems.  It provided enough power to build enterprise grade applications, while still being easy and flexible enough to be the super-glue of many systems.

I’m sure Perl will still be with us in another 20 years.  I wish it to be as useful in that time, as it is now.

Thanks, respect, and best wishes to everyone who created and supported Perl, its community and tools all these years.  Happy birthday!