Skip to content

Instantly share code, notes, and snippets.

Created April 13, 2011 18:52
Show Gist options
  • Save padraic/918126 to your computer and use it in GitHub Desktop.
Save padraic/918126 to your computer and use it in GitHub Desktop.
Package spec as a PHP 5.3 closure?
$package = function ($s) {
$s->name = 'Overlord';
$s->authors = 'Padraic Brady, Sauron[]';
$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 = '';
$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';
Copy link

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

Copy link

padraic commented Apr 13, 2011

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.

Copy link

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?

Copy link

padraic commented Apr 14, 2011

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 ;).

Copy link

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;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment