Re: phar: problem with renaming implementation

Steph Fox wrote: > I'm not sure whether this factory method should be internal or > exposed... my instinct would be to keep it internal because > convertToZip() etc are very intuitive, as method names go. fine >> compressAllFiles*() would go back to its original purpose of compressing >> individual files within the archive (and would throw an exception if >> called for tar-based phar archives). > > I'm not 100% sure what you mean by that... Does anyone (except you > presumably) knowingly compress each separate file within an archive? this is the only way to compress all files inside a zip archive (which are uncompressed by default in phar), and is the only way to generate a phar-based phar archive that has compressed files which can still be run without ext/phar, as whole-file compression would compress the stub as well. So, yes. > Altogether, if we're revamping that part of the API I'd like to keep > it simple for the casual user: > > compress(Phar::GZ|BZ2) - returns a handle to the compressed file or > FALSE > isCompressed() - returns Phar::GZ|BZ2|FALSE > either of 'uncompress()' or 'decompress()' - returns a handle to the > decompressed file or FALSE > > - this the same naming for Phar, PharData and PharFileInfo. If you > _also_ want compressAllFiles() and it means something different, bags > you do the docs for it :) The existing docs already describe what it should do. >> Finally, we need a method for grabbing the phar filename. > > ? internal or exposed? (Not entirely sure what you mean here either.) if the filename changes, how does the enduser know what the new filename is? exposed. >> Discussion should ensue, and I'm also curious whether you want to take >> this on Steph? It should result in MUCH simpler code and logic for our >> debugging purposes as well as in the end-user PHP level. > > More than happy to - relieved, even - with the caveat that I'd like > those bits I'm not clear about, clarified. Apart from that, you just > keep up the rear end with the battle for stream wrapper access to > include_path ;) Good. I've got 5.2 working, and am finally tackling the bugs at pecl.php.net. The next step is going to be getting that ZF app working and then we'll be ready for a release of the 2.0 strain to get these new features more battle-tested. Greg