Closures inside property initializations inside the class body don't work. Not even in an array.

So this code throws up a "Parse error: syntax error, unexpected 'function' (T_FUNCTION)"

    class User
    {
        public static $mapping = array(
            'username' => array(
                'type' => 'string',
                'length' => 32,
                'unique' => true,
                'nullable' => function() {
                    // Some logic to determine value.  
                }
            )
        );  
    }

Came here to post the same thing. I don't know if it has been fixed in 5.4, though.

Nope, the parser seems to be pretty brittle around this. Someone who knows more about the internals can probably explain why this works:

  class User
  {
      public $mapping = array(
          'username' => array(
              'type' => 'string',
              'length' => 32,
              'unique' => true,
          )
      );  

      public function __construct()
      {
      	$this->mapping['nullable'] = function() { echo "test"; };
      	$this->mapping['nullable']();
      }
  }

  $user = new User();

And this doesn't:

  class User
  {
      public static $mapping = array(
          'username' => array(
              'type' => 'string',
              'length' => 32,
              'unique' => true,
          )
      );  

      public static function set()
  	{
  		self::$mapping['nullable'] = function() { echo "test"; };
  		self::$mapping['nullable']();
  	}
  }

  User::set();

I used to be interested in helping fix PHP, but I gave up.

The reason is because Rasmus and a few others seem to think that using the syntax definition to do your type checking for you is a good idea, and that the hundreds of possible cases they didn't think of, don't matter.

Don't need to inline the function, it could instead just be a reference to static member of the same class: ... 'nullable' => self::getNullable, ...

'nullable' => self::getNullable

also won't work in any version of PHP

I don't think that everything must be object oriented in the standard library, though I'm not a big fan of the functions in global namespace either.

The structure of Go's standard library could be a good inspiration for restructuring PHP's standard library.

I don't think that shared hosting needs to be fixed before you can benefit from a good package manager.

Composer and Pyrus both are able to install packages local to the project.

So just grab the dependencies before and then upload the "damn thing" to the server to deploy and this will work on every shared host out there.

Sure, you can get part of the benefit even if you're on shared hosting. (Off-topic but related example: I use git to manage projects locally even if they are going to be deployed to a server that doesn't support git. Last week I finally moved a small-business client to a git-enabled host, and it was such a relief.) But it's only part of the benefit.

A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever.

Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.

The problems you mention are why user land components should be used where possible and wrap builtins. Install the components local to the project and you control the outcome.

Exactly that was my point.

Currently it does not solve the problem of the sh*tload of dependencies, though I'm filing an issue for now.

php-build currently solves mainly the problem of configuring PHP correctly, so the build is isolated to the prefix it's installed in (it also sets up PEAR or Pyrus correctly).

Currently I'm using it with Linux (Ubuntu, Fedora) and on my OSX Lion powered Macbook Air.

...phpenv (https://github.com/CHH/phpenv)

The mission of php-build is to reduce my workflow of testing new PHP versions to one command I can run. php-build also provides a opinionated default configuration, which you can build on and extend.

Without php-build I have to do this when I want to test, for example PHP 5.4.0RC1:

1. Find a tarball 2. Extract Tarball 3. Configure it 3a. If I already have a script to configure this version go to 4. 3b. Pick configure options (PHP has a sh*tload of them) 3c. See if it works 4. make && make install 5. install Pyrus 6. install XDebug 7. install PHPUnit

So with php-build (and php-build-plugin-phpunit): 1. php-build -i development 5.4.0rc1 ~/.phpenv/versions/5.4.0rc1 2. ? 3. Profit

First, a tablet doesn't let you just do those things.

I made the "80%" up, but the list should only capture what most of the people most of the time do with their computers. If you want to do the one more thing, there will always be more software for that, also for your tablet.

My point is that Tablets are the new _personal_ computer and what we knew as PC before is now going to be the _workstation_.

I talked about simple office tasks like writing a letter, writing a CV, or a simple handout. These are all things that are at most one page, which can be done with a tablet without much pain.