Home

Want to get started using or contributing to pestle? Start here.

Need help understanding how to pass arguments to your program? Read the arguments and options document

Why Pestle

Pestle grew out of my desire to write PHP in a "python like" way. That is, to have

1. A non-default-global namespace
2. The ability to import functions from other modules
3. The ability to import all functions from other modules
4. Small functions operating on scalar and list data

When PHP announced namespaces in PHP 5.3, I was initially excited. However, PHP 5.3 namespaces didn't have great support for functions. They understood functions, but the use keyword only worked with classes.

More modern versions of PHP (5.6+, 7.0) introduced the use function -- but this only works with already loaded PHP code files. i.e. you'd need to load all your module files at once. PHP solves this with classes using the SPL autoloader, but registered autoloaders don't fire for undefined functions. The use function is also missing the ability to load all the functions from a namespace. i.e. similar to python code that looks like this

import time;
print time.time();

PHP's evolution towards a class/interface based programming system is probably the right one for widespread adoption and business support, but I've always been curious what it would be like to work with PHP if it had gone the other way. That's part of what the pest project is about.

Other Project Guidelines

Given pestle is an experiment, there's lots of other unspoken guidelines/values that are emerging. These aren't hard and fast rules, and even if they were rules are meant to be broken. They're more framing devices to help understand why the project's in the state it is, and the direction we're heading. Discussions on all this are more than welcome.

1. A bias towards "make it work first, make it right second"
2. A bias towards "I made it do this" vs. "I'd like it to do this"
3. Be open to using third party libraries for commands, but core pestle functionality should be a part of the project itself (argument parsing, eventual readline support, etc.)
4. Give everyone room to make mistakes, and do what they want in modules. Critique is welcome (and vital) but only if its kind.