Month: May 2007

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!