20 possible reasons why PHP function names and parameters are weird

Here are 20 possible reasons why PHP functions lack consistent names and parameters. Learning the definition for every PHP function is truly an amazing feat and I doubt this has been attempted or accomplished by anyone. At least, by any sane human. And references are named references because they are designed to be referenced, right?

The List:

  • PHP glues APIs and humans together, and sometimes this gets messy
  • PHP documenters pull strings to force a dedicated audience
  • PHP is gearing up for a massive quiz on every function signature to rival all pi (π) competitions
  • PHP likes BC
  • PHP thrives on making your life difficult… because it’s fun
  • PHP is working on a time machine so really none of this matters
  • PHP gladly and openly steals ideas and usage from other languages
  • PHP says all your namespace are belong to us
  • PHP functions have been developed under many circumstances, sometimes drunk
  • PHP is a recursive acronym
  • PHP anarchy says rules? we don’t need no stinkin’ rules!
  • PHP function naming algorithm still remains a secret and cannot be cracked
  • PHP chose to give people something fun to complain/blog/laugh about
  • PHP function aliases are for the weak
  • PHP functions created in the 90’s (and some later) directly used prototypes from low-level APIs
  • PHP isn’t designed to win a beauty contest
  • PHP has other problems to solve
  • PHP needed a way to explain having an elephant for a logo
  • PHP encourages text editors to be intelligent => code insight
  • PHP.net + Ads = $$$

Related Resources:

Related Quiz Questions:

  • Write the prototype for: in_array, isset, empty, strpos, strstr, subtr, implode
  • Find the aliases: die, exit, echo, print, mysql, strchr, strstr, implode
  • Locate the functions: die, echo, print, include, isset, unset, array, rtfm, str_parse, implode
  • Define these PHP terms: Deprecated, Minor release, Major release, PECL, TSRM, Open Source, Rules

The day I became editor of the PHP manual

Today (or yesterday, or maybe tomorrow) marks a big day in my life because it’s the day I became editor of the PHP Manual. The request to take over as editor was not easy because it’s a position that requires work and responsibility… and consistent time. Working on the manual (something I’ve done since 2001) requires no true time commitments or required responsibilities because you submit documentation when you feel like it, solve the bugs you want, work on tasks that smell interesting, and take breaks whenever. In these past years I’ve taken many breaks because breaks are good but today I’m required to do something, required to be responsible for being there. I happily accept this challenge and must confess… I love PHP.

The documentation team is a good group of people with too many worthy names to mention here but [un]fortunately many of us have grown old. And since time has a way of adding new responsibilities, the total time spent writing documentation has decreased for most contributors. We’re looking for fresh warm bodies to join the team so if you like to write words read by millions, and work with fellow PHP friends, then make mom proud and join in on the fun. Don’t be shy! Most of us are normal people too.

Thanks to everyone for supporting this decision, I look forward to helping the team improve the PHP Manual over the next year or more. In my letter to the group you’ll notice that a “one year exit option” snuck into the contract… clever huh? :) And thank you Gabor Hojtsy for doing such a great job as editor because over the years you’ve had a positive impact on my life and your legacy will be continued. Drupal is lucky to have you as a core maintainer.

Now, only a few pages of this required reading left to go and then it’s time to work on that lengthy todo list … it’s go time!

A brief unofficial history about register_globals in PHP

It’s been a long road and exactly five years (35 releases) since the much discussed and highly controversial PHP directive register_globals has been disabled by default in PHP. After sifting through the mailing list archives, the following set of information has been compiled. Feel free to make additions, corrections, and report register_globals memories!

First, a few tidbits

  • As of today, April 22, 2007, register_globals has been disabled (by default) for five years. That’s when PHP 4.2.0 was released.
  • PHP 3 did not have register_globals because it was simply how PHP behaved. However, some people used $HTTP_*_VARS if track_vars was on (it was on by default, and always on since PHP 4.0.3).
  • You cannot set register_globals at runtime, and there have been at least 100 [deleted] user comments within the manual showing hacks how. This FAQ shows how. Don’t do it though.
  • The order variables are registered via register_globals is determined by variables_order, a directive that also affects which variables (including superglobals) will exist in PHP. Don’t let the name fool you, this is one powerful PHP directive! In PHP 3, gpc_order was used instead.
  • Most “Why PHP is insecure” articles show how to write insecure code with register_globals = on, and eventually register_globals (not poor programming) is blamed as the culprit. It rarely is.
  • Strangely the 4.2.0 release announcement does not contain the string “register_globals” but of course it refers to it, and is highlighted in the ChangeLog.
  • There’s plenty of code within cvsold.php.net that requires register_globals = on but that’s okay because it’s not a big concern. It however is slowly being updated.

A somewhat brief timeline

Continue reading A brief unofficial history about register_globals in PHP

a little roshambo dot org

This was from awhile ago:

a screenshot of roshambo.org
sometime early april 2007

And now today:

roshambo taken recently, on april 18, 2007

Is it random? What is random? Yes it’s random.

UPDATE: Some have asked if the numbers here are special… they aren’t. Well, the 925,952,925 struck me whereas the other was randomly chosen while writing this post.