Package spec as a PHP 5.3 closure?

.package.php

<?php

$package = function ($s) {
    $s->name = 'Overlord';
    $s->authors = 'Padraic Brady, Sauron[sauron@mordor.me]';
    $s->version = '0.0.1-dev';
    $s->api_version = '0.0.1-dev';
    $s->summary = 'Monitoring library for Hobbit Detector 1.0';
    $s->description = file_get_contents(__DIR__ . '/description.txt');
    $s->homepage = 'http://en.wikipedia.org/wiki/Sauron';
    $s->changelog = file_get_contents(__DIR__ . '/changelog.txt');
    $s->files->php[] = 'library/**/*.php';
    $s->files->tests[] = 'tests/**/*.*';
    $s->files->reject[] = '*.project';
    $s->files->bin[] = 'scripts/overlord.bat';
    $s->include_path = 'MutateMe/Mutations/';
    $s->dependencies[] = 'PHP[>=5.3.1]';
    $s->dependencies[] = 'Pear[>=1.6.5]';
    $s->dependencies[] = 'MutateMe[0.5.0]';
    $s->dependencies[] = 'ext/runkit';
    $s->optional_dependencies[] = 'ext/eyeofsauron';
    $s->license = 'New BSD';
};

When would you want to pass in more than one different project as $s which shares all those properties?

The objective is to create an interoperable format in native PHP for defining PEAR package metadata. I could reference methods, but that would be too verbose. I could reference a specific class, but that would tie it to one specific implementation. End of the day, I don't want anyone tied to one specific packager. The number of properties isn't that big - they can be set on any old class, and processed into any other desired object form by the packager itself.

I see what you mean. With this approach, you seem to hijack variables of a class though.

Plus, the config is spread all over the project (e.g. could those properties be applied to all ZF2's files?) What would the winnings be compared against a one-file-config such as the same php array in a bundled pear_properties.php?

As opposed to an instance of stdClass? I prefer the object oriented syntax - less quoting, and more readable. It's simply a personal preference. Something like Zend Framework could use it (theoretically). Just define a bunch of package files (.package is merely a suggested name). The glob style file patterns can sort out what to include or not. ZF is already heading off into generation for ZF 2.0 - based on phpdoc comments and namespace usage. Using a set of closures would, I think, be miles easier. This is merely an idea, of course ;).

No, not opposed to a stdClass. I'm rather trying to find out why it's necessary to have an "is-a" relationship by tagging $s (still not sure of what's being passed in) with a function, instead of a more compressed "has-a" relationship like

$package = new stdClass;
$package->name = 'Overlord';
...
$s->package = $package;