Re: Re: attempting to work out conversion/compressionAPI

Lars Strojny wrote: > Hi Steph, > > Am Donnerstag, den 10.04.2008, 13:46 +0100 schrieb Steph Fox: > [...] >> I think the main problem with this approach is that there are four >> arguments >> from inception, three of which are likely to be used most of the >> time. >> Personally I have problems remembering more than two parameters :) >> especially when there are extension-specific constants involved. >> >> The advantage of having separate methods for >> convertToTar()|convertToPhar()|convertToZip() is that it removes at least >> one of those arguments, leaving only $compression, $executable and >> $file_extension to worry about in the first two methods and only $executable >> and $file_extension in convertToZip(). Given that most people are unlikely >> to use $file_extension anyway, I think that would make it much easier to >> both remember and read. So I'd rather have: > > And again, the problem is here is, that it exposes implementation > details ("the available archive formats") to a generic user API. This is > why I would heavily vote against convertTo*() methods. I also have reservations about my own proposal if we remove compress() and put the compression into convertTo*(), as then it becomes non-intuitive to compress a tar archive: <?php $a = new Phar('blah.phar.tar'); $b = $a->convertToTar(Phar::GZ); // I'm compressing, not converting the archive format ?> This needs more thought. How does this syntax look: Phar Phar->convertToExecutable([archiveformat = null][, compression = null][, extension = null]) PharData Phar->convertToData([archiveformat = null][, compression = null][, extension = null]) This removes 1 parameter, and completely separates the conversion to an executable phar or a data phar. The API is much clearer to read, and removes 1 very non-obvious parameter. Most users will use only the first 2 parameters. null = keep default format. Now we have: <?php $a = new Phar('blah.phar.tar'); $b = $a->convertToExecutable(Phar::TAR, Phar::GZ); // create executable phar.tar.gz $c = $a->convertToData(Phar::ZIP); // create data .zip $d = $a->convertToData(); // create data .tar $e = $b->convertToData(); // create data .tar.gz ?> I would also like an explicit method of unlinking the underlying file, so that one can do: <?php $a = new PharData('blar.tgz'); $b = $a->convertToExecutable(); $a->unlink(); // unlinks blar.tgz, and removes it from the manifest in-memory $a->*() // throws exception - phar is unusable $a = new PharData('blar.tgz'); // creates new tgz with no relation to blar.tgz ?> This is because simply doing an unlink() on the file will not allow one to "start over" with the last line of the above script. Steph/Lars - can we agree on this API? I'm implementing compressFiles() as there was no dissent. Greg