Lester Caine wrote: > Gregory Beaver wrote: >> Phar is not yet perfect, but is also not NEARLY as complex as PDO. >> There is no comparison. > > The 'comparison' was in the way these packages get added without proper > investigation ;) Someone decides that THIS is how it will be done, and > that is what happens :( and we have to live with the consequences.
Please, this is ridiculous, your response is completely out of proportion to what is happening. Marcus proposed the addition of phar to core in 5.3, and is now asking for public comment. > How would I use 'phar' with the four thousand files that make up > bitweaver? I have had a quick look, but I don't yet see how I handle all > the installation and management options for installing and updating > packages that bitweaver has been designed to support. ADOdb and smarty > provide the core libraries, and the liberty shell is built on those. > Only those packages that are needed are download to the target system. I > suspect we would have to build phar files for each package, but > currently styles and themes can easily be managed via a few file > changes, something that phar would seem to make a lot more difficult. > Private tweaks to the libraries provide performance and operational > improvements that would not be possible if ADOdb or smarty were supplied > 'packed'. But without example phar libraries to look at and pull apart > proper investigation is difficult - as people have already said. phar is best for self-contained libraries or applications that do not need to modify their source code. Many applications (like phpmyadmin) do configuration by modifying a source code file and then including it. This practice would require that the phar.read_only INI setting be off in php.ini (it is on by default). Also useful and not yet implemented would be to allow include_path to have a phar:// archive, as many issues with "pharring" applications would no longer exist. Controversy doesn't even begin to describe the reaction I expect from this suggestion, however. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
