Tuesday

If PHP Were British

When Rasmus Lerdorf first put PHP together, he - quite sensibly, despite his heritage - chose not to write it in Greenlandic or Danish. Good job too - that would have been rather unpleasant to work with. He opted instead, being in Canada at the time, for the local tongue. No, not French - that bastard dialect of the Queen's English commonly referred to as "US English"1.

PHP developers in Britain have been grumpy about this ever since. What was he thinking? And more importantly, how do we undo this travesty? How do we developers ensure the traditions of the British Empire continue to be upheld, even in the digital age?

A Slap in the Face

  1. $variable_name

The first, but maybe the most important, of many changes that will allow PHP to achieve a more elegant feel is to remove that symbol so beloved by the US and replace it with something altogether more refined. More solid. More ... sterling.

  1. £variable_name

Getting Started

  1. echo 'Hello World!';
  2. ?>

How many of today's British programmers have been put off at the outset by the brazen informality of this simple yet obscenely Americanised program, colloquially referred to as "Hello World"? A more Imperial, formal introduction might encourage a greater proportion of young British talent to remain with the language and thus give the broader community a more urbane air.

  1. announce 'Good morrow, fellow subjects of the Crown.';
  2. ?>

Abbreviations

Few things are more abhorrent to the British than unnecessary abbreviations. "Text speak" is unheard of on the streets of London, as the natural ingrained British grammarian simply refuses to stoop to sending messages of the "c u soon traffic kthxbye" variety, instead proferring something altogether more elegant: "Dear Sir/Madam. I will arrive as soon as time allows, which I expect to be within the hour. I assure you the horses shall not be spared. Yours respectfully." (slower to type, yes, but we do not like to be rushed).

PHP, on the other hand, is full to bursting with abbreviations and acronyms which are entirely unnecessary:

  1. str_replace()
  2. is_int()
  3. var_dump()
  4. preg_match()
  5. json_encode()
  6. mysql_connect()

The following changes should improve things:

  1. string_replace()
  2. is_integer()
  3. variable_dump()
  4. perl_regular_expression_match()
  5. javascript_object_notation_encode()
  6. my_structured_query_language_connect()

Edit: I have corrected the expansion of "preg_match" - thanks to those who pointed it out.

Eloquence

  1. if ($condition) {
  2. // Code here
  3. } else {
  4. // Code here
  5. }

Shakespeare would be ashamed to see his native tongue twisted into this monstrosity. Brevity is to be applauded in the right context - in some dark corner, where it shall be seldom seen - but not here. The if ... else block is the most used conditional code in all of PHP, so it must be made as inoffensive as possible. There are many options for its replacement, but this may be the strongest:

  1. perchance (£condition) {
  2. // Code here
  3. } otherwise {
  4. // Code here
  5. }

The same naturally applies to the Americanised switch ... case construct, which one can only describe as clunky and unpleasant:

  1. switch ($variable) {
  2. case $option1:
  3. //Code here
  4. break;
  5. case $option2:
  6. //Code here
  7. break;
  8. default:
  9. //Code here
  10. break;
  11. }

Words such as "switch", "break" and "default" are hard on the reader and lack context. The Right Honorable biggerthancheeses was kind enough to contribute a more gentrified suggestion (and has some interesting ideas, particularly around replacement of "include()" with something like "i_might_be_partial_to()", demonstrating a natural talent for the Imperialisation of programming languages):

  1. what_about (£variable) {
  2. perhaps £possibility:
  3. //Code here
  4. splendid;
  5. perhaps £other_possibility:
  6. //Code here
  7. splendid;
  8. on_the_off_chance:
  9. //Code here
  10. splendid;
  11. }

Spelling

  1. imagecolorallocate()
  2. serialize()
  3. newt_centered_window()
  4. connection_status()

Words fail me at this point. How is any self-respecting gentleman expected to make head or tail of these "words". It beggars belief that anyone could allow such distortions of words to be entered into a programming language. They, along with the cornucopia of similar errors, should be reverted to their proper forms immediately:

  1. imagecolourallocate()
  2. serialise()
  3. newt_centred_window()
  4. connexion_status()2

Manners

  1. try {
  2. // Code here
  3. } catch (Exception $e) {
  4. // Handle exception
  5. die('Message');
  6. }

The try ... catch block is an excellent example of PHP's lack of manners. Far too direct to be allowed in the new PHP. Additionally, the word "die" is so very depressing. This new block, although more verbose, is vastly more polite and upbeat:

  1. would_you_mind {
  2. // Code here
  3. } actually_i_do_mind (Exception £e) {
  4. // Politely move on
  5. cheerio('Message');
  6. }

Class

Perhaps nothing is as important and ingrained in the British psyche as the notion of class and, while there are few opportunities for change within this part of PHP, the changes that there are to be made here are important.

  1. class Republic {
  2. public $a;
  3. private $b;
  4. protected $c;
  5. }
  6. $example = new Republic;

To begin with, the current system has no place for class hierarchy and this is unacceptable. So we shall begin by giving classes specific levels - upper, middle, working - and no class can access the methods of one of a higher level without the explicit permission of the higher order class (of course, though it might then have access, it would not be a true member of the higher order and could not itself grant higher order access to other lower order classes). "Public" and "Private", in the British class system, are often synonymous (see, for example, school system nomenclature), so these must be adjusted, as should the "Protected" property visibility. The word "new", while passable, has a much more appropriate replacement in matters of class.

  1. upper_class Empire {
  2. state £a;
  3. private £b;
  4. hereditary £c;
  5. }
  6. £example = nouveau Empire;

The Sun Never Sets ...

It is hoped that these few simple changes will improve the reputation and status of PHP among other languages. No longer will it be the poor American cousin - instead it can take its rightful place as the - British - King of the scripting languages.

Thanks

Many thanks to Mark and Pat, colleagues at GSBA, who started this resurrection of the British Empire in the pub on Friday.

1. Ok, the neighbouring local tongue.

2. Yes, connexion.

Saturday

The future of PHP

PHP is already popular, used in millions of domains (according to Netcraft), supported by most ISPs and used by household-name Web companies like Yahoo! The upcoming versions of PHP aim to add to this success by introducing new features that make PHP more usable in some cases and more secure in others. Are you ready for PHP V6? If you were upgrading tomorrow, would your scripts execute just fine or would you have work to do? This article focuses on the changes for PHP V6 — some of them back-ported to versions PHP V5.x — that could require some tweaks to your current scripts.

If you're not using PHP yet and have been thinking about it, take a look at its latest features. These features, from Unicode to core support for XML, make it even easier for you to write feature-filled PHP applications.

New PHP V6 features

PHP V6 is currently available as a developer snapshot, so you can download and try out many of the features and changes listed in this article. For features that have been implemented in the current snapshot, see Resources.

Improved Unicode support

Much improved for PHP V6 is support for Unicode strings in many of the core functions. This new feature has a big impact because it will allow PHP to support a broader set of characters for international support. So, if you're a developer or architect using a different language, such as the Java™ programming language, because it has better internationalization (i18n) support than PHP, it'll be time to take another look at PHP when the support improves.

Because you can download and use a developer's version of PHP V6 today, you will see some functions already supporting Unicode strings. For a list of functions that have been tested and verified to handle Unicode, see Resources.

What is Unicode?

Unicode is an industry-standard set of characters, character encoding, and encoding methodologies primarily aimed at enabling i18n and localization (i10n). The Unicode Transformation Format (UTF) specifies a way to encode characters for Unicode. For more information about Unicode and UTF, see Resources.

Namespaces

Namespaces are a way of avoiding name collisions between functions and classes without using prefixes in naming conventions that make the names of your methods and classes unreadable. So by using namespaces, you can have class names that someone else might use, but now you don't have to worry about running into any problems. Listing 1 provides an example of a namespace in PHP.

You won't have to update or change anything in your code because any PHP code you write that doesn't include namespaces will run just fine. Because the namespaces feature appears to be back-ported to V5.3 of PHP, when it becomes available, you can start to introduce namespaces into your own PHP applications.


Listing 1. Example of a namespace
                  

Web 2.0 features

Depending on how you use PHP and what your scripts look like now, the language and syntax differences in PHP V6 may or may not affect you as much as the next features, which are those that directly allow you to introduce Web 2.0 features into your PHP application.

SOAP

SOAP is one of the protocols that Web services "speak" and is supported in quite a few other languages, such as the Java programming language and Microsoft® .NET. Although there are other ways to consume and expose Web services, such as Representational State Transfer (REST), SOAP remains a common way of allowing different platforms to have interoperability. In addition to SOAP modules in the PHP Extension and Application Repository (PEAR) library, a SOAP extension to PHP was introduced in V5. This extension wasn't enabled by default, so you have to enable the extension or hope your ISP did. In addition, PEAR packages are available that allow you to build SOAP clients and servers, such as the SOAP package.

Unless you change the default, the SOAP extension will be enabled for you in V6. These extensions provide an easy way to implement SOAP clients and SOAP servers, allowing you to build PHP applications that consume and provide Web services.

If SOAP extensions are on by default, that means you won't have to configure them in PHP. If you develop PHP applications and publish them to an ISP, you may need to check with your ISP to verify that SOAP extensions will be enabled for you when they upgrade.

XML

As of PHP V5.1, XMLReader and XMLWriter have been part of the core of PHP, which makes it easier for you to work with XML in your PHP applications. Like the SOAP extensions, this can be good news if you use SOAP or XML because PHP V6 will be a better fit for you than V4 out of the box.

The XMLWriter and XMLReader are stream-based object-oriented classes that allow you to read and write XML without having to worry about the XML details.


Things removed

In addition to having new features, PHP V6 will not have some other functions and features that have been in previous versions. Most of these things, such as register_globals and safe_mode, are widely considered "broken" in current PHP, as they may expose security risks. In an effort to clean up PHP, the functions and features listed in the next section will be removed, or deprecated, from PHP. Opponents of this removal will most likely cite issues with existing scripts breaking after ISPs or enterprises upgrade to PHP V6, but proponents of this cleanup effort will be happy that the PHP team is sewing up some holes and providing a cleaner, safer implementation.

Features that will be removed from the PHP version include:

  • magic_quotes
  • register_globals
  • register_long_arrays
  • safe_mode

magic_quotes

Citing portability, performance, and inconvenience, the PHP documentation discourages the use of magic_quotes. It's so discouraged that it's being removed from PHP V6 altogether, so before upgrading to PHP V6, make sure that all your code avoids using magic_quotes. If you're using magic_quotes to escape strings for database calls, use your database implementation's parameterized queries, if they're supported. If not, use your database implementation's escape function, such as mysql_escape_string for MySQL or pg_escape_string for PostgreSQL. Listing 2 shows an example of magic_quotes use.


Listing 2. Using magic_quotes (discouraged)
                  

After preparing your PHP code for the new versions of PHP, your code should look like that in Listing 3.


Listing 3. Using parameterized queries (recommended)
                 prepare("INSERT INTO USERS (USERNAME) VALUES ?"); $statement->execute(array($_GET['username'])); ?> 

Now that support for magic_quotes will be completely removed, the get_magic_quotes_gpc() function will no longer be available. This may affect some of the older PHP scripts, so before updating, make sure you fix any locations in which this functions exists.

register_globals

The register_globals configuration key was already defaulted to off in PHP V4.2, which was controversial at the time. When register_globals is turned on, it was easy to use variables that could be injected with values from HTML forms. These variables don't really require initialization in your scripts, so it's easy to write scripts with gaping security holes. The register_globals documentation (see Resources) provides much more information about register_globals. See Listing 4 for an example of using register_globals.


Listing 4. Using register_globals (discouraged)
                  

If your PHP code uses global variables, you should update it. If you don't update your code to get prepared for newer versions of PHP, consider updating it for security reasons. When you're finished, your code should look like Listing 5.


Listing 5. Being specific instead (recommended)
                  

register_long_arrays

The register_long_arrays setting, when turned on, registers the $HTTP_*_VARS predefined variables. If you're using the longer variables, update now to use the shorter variables. This setting was introduced in PHP V5 — presumably for backward-compatibility — and the PHP folks recommend turning it off for performance reasons. Listing 6 shows an example of register_long-arrays use.


Listing 6. Using deprecated registered arrays (discouraged)
                  

If your PHP code looks like that shown in Listing 6, update it to look like that in Listing 7. Shut off the register_long_arrays setting if it's on and test your scripts again.


Listing 7. Using $_GET (recommended)
                  

safe_mode

The safe_mode configuration key, when turned on, ensures that the owner of a file being operated on matches the owner of the script that is executing. It was originally a way to attempt to handle security when operating in a shared server environment, like many ISPs would have. (For a link to a list of the functions affected by this safe_mode change, see Resources.) Your PHP code will be unaffected by this change, but it's good to be aware of it in case you're setting up PHP in the future or counting on safe_mode in your scripts.

PHP tags

Microsoft Active Server Pages (ASP)-style tags — the shorter version of the PHP tags — are no longer supported. To make sure this is not an issue for your scripts, verify that you aren't using the <% or %> tags in your PHP files. Replace them with and ?>.

FreeType 1 and GD 1

The PHP team is removing support for both FreeType 1 and GD 1, citing the age and lack of ongoing developments of both libraries as the reason. Newer versions of both of these libraries are available that provide better functionality. For more information about FreeType and GD, see Resources.

ereg

The ereg extension, which supports Portable Operating System Interface (POSIX) regular expressions, is being removed from core PHP support. If you are using any of the POSIX regex functions, this change will affect you unless you include the ereg functionality. If you're using POSIX regex today, consider taking the time to update your regex functions to use the Perl-Compatible Regular Expression (PCRE) functions because they give you more features and perform better. Table 1 provides a list of the POSIX regex functions that will not be available after ereg is removed. Their PCRE replacements are also shown.


Table 1. ereg() functions and their PCRE equivalents
ereg() functionSimilar preg() function
ereg(), eregi() preg_match()
ereg_replace(), ereg_replacei() preg_replace()

PHP V5.3

Some of the features mentioned here have also been ported to PHP V5.3, which is scheduled to be released during the first quarter of 2008. You may want to upgrade to V5.3 and start using these features now, so that when you move to V6 of PHP, it'll be less of a jump. The following list of features have been back-ported to V5.3:

  • Namespaces
  • XMLReader and XMLWriter in core by default

About the author

Nathan Good lives in the Twin Cities area of Minnesota. Professionally, he does software development, software architecture, and systems administration. When he's not writing software, he enjoys building PCs and servers, reading about and working with new technologies, and trying to get his friends to make the move to open source software. He's written and co-written many books and articles, including Professional Red Hat Enterprise Linux 3, Regular Expression Recipes: A Problem-Solution Approach, and Foundations of PEAR: Rapid PHP Development.

Wednesday

Facebook looks to speed up PHP

The internally-developed HipHop for PHP source code transformer is being offered via open source


Technologists at Facebook on Tuesday are releasing a source code transformer intended to boost the performance of PHP.

In development for the past two years, the technology, called HipHop for PHP, has been used to reduce the CPU usage on Facebook Web servers by an average of about 50 percent, said Haiping Zhao, senior server engineer at Facebook.

[ InfoWorld reported on PHP 6 highlights, including internationalization, that were detailed at a technical conference late last year. ]

"The project has had a tremendous impact on Facebook. We feel the Web at large can benefit from HipHop, so we are releasing it as open source this evening in hope that it brings a new focus toward scaling large, complex Web sites with PHP," Zhao said in a statement on the Facebook Developers page.

The technology is not complete and users need to be comfortable with HipHop before trying it out, said Zhao.

HipHop, he said, technically is not a compiler. It features a code transformer, a reimplementation of PHP's runtime system and a rewrite of some common PHP extensions to boost performance optimizations.

"HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it," Zhao said. "HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features -- such as eval() -- in exchange for improved performance."

PHP, Zhao said, offers benefits in terms of programmer productivity, as do other scripting languages such as Perl, Python and Ruby. But scripting languages are known to be less efficient in terms of CPU and memory usage, he said.

"Because of this, it's been challenging to scale Facebook to over 400 billion PHP-based page views every month," Zhao said.

HipHop allows developers to keep the best aspects of PHP while taking advantage of performance of C++, said Zhao.

"In total, we have written over 300,000 lines of code and more than 5,000 unit tests. All of this will be released this evening on GitHub under the open source PHP license," Zhao said.

The CEO of PHP tools maker Zend Technologies questioned how much of HipHop was Facebook-specific.

"It will be interesting to learn what HipHop concepts apply to the broad PHP community and what are specific to Facebook," said Andi Gutmans, of Zend. "We have always adapted to changes within the PHP runtime, whether these changes were made by us or by the community and will be glad to continue doing so. We believe it is important to continue to fold in new ideas and innovations into the community-based runtime."

This story, "Facebook looks to speed up PHP," was originally published at InfoWorld.com. Follow the latest developments in software development at InfoWorld.com.

Paul Krill is an editor at large at InfoWorld, focusing on coverage of application development (desktop and mobile) and core Web technologies such as HTML5, Java, and Flash.

Beyond Spot-Checking: Why LLM Applications Require Specialized Evaluation

  images generated by meta ai Building applications with Large Language Models (LLMs) feels deceptively fast at first. A single engineer can...