Re: [REMINDER] Package Proposal: Tools and Utilities::BackPort

Greg Beaver wrote:

Hi again, I think people might be a little confused about the problem BackPort solves, it's not entirely clear how this fixes issues of compatibility and portability. Could you excerpt a bit of the php mag article, or summarize the key points? As for me, my only question is how multiple packages using BackPort in the same application will co-exist. Perhaps BackPort could be a singleton and so raise errors if there are conflicts between two definitions of the same element, and particularly if two packages need different ini settings for the same variable. Regards, Greg Davey wrote:

Just a reminder about BackPort. Current voting status +2 New names if you feel its needed, though I have written about this in my article for PHP Magazine and it will print as being called BackPort Original Messages (quoted) here: http://news.php.net/article.php?group=php.pear.dev&article=17807 and updated here: http://marc.theaimsgroup.com/?l=pear-dev&m=105687716414094&w=2 A definate yes/no on this would be appreciated :) - Davey

The idea is this: Tell the class the names of functions, classes and extensions what functions you want it to handle and how it should handle them. You basically do this: <?php require 'backport.php'; $backport = new backport; /* file_get_contents function only got added in PHP 4.3.0 - we want to fallback to fileLoad in fileLoad.func.php if we need too */ $backport->registerFunction('file_get_contents','fileLoad','fileLoad.func.php'); /* Add our dependency for the function, in this case its a version depenency, we 'load' a file if it doesn't meet the requirements (more than or equal to PHP 4.3.0) */ $backport->addDependency('file_get_contents','version',E_ERROR,'load','4.3.0','>='); /* call our function through the framework, arg1 == function, arg2+ == args for it */ $file_contents = $backport->callFunction('file_get_contents','backport.diff'); echo "<pre>" .$file_contents. "</pre>"; ?> I know this can look kinda long winded, but its *very* speedy and allows really great flexibility, and allows your application to degrade gracefully depending on the OS/PHP Version. You are able to hide portions of a script that will not run within the current circumstances PHP is in. For example, you have a news application, you want to allow people to upload images and have the script generate thumbnails. What if PHP doesn't have GD? well this allows you to a) load the right extension file (you can specify a file for nix, for windows and even a PHP implementation) or b) simply hide that part of the script. i.e. the button that said "Upload Thumbnail!" is hidden :) Note that with what I said above, if you for example you only specify the unix module and then a PHP implementation, on windows it'll go straight to the PHP implementation, likewise, if trying to dl() would cause an E_ERROR (enable_dl = off || safe_mode = on) then it goes straight to the PHP implementation instead of trying to dl(). I think once I get some proper DocBook stuff written for it, it'd be a lot easier to understand the full power of what it can do. By the way, I'd release this code as Stable most likely, I did quite a bit of testing and messing about with it whilst I was writing my article :) - Davey