into 2 methods:
convertToExecutable/convertToData. Both methods accept 3 optional parameters
1 archive type, Phar::PHAR, Phar::TAR, or Phar::ZIP
2 compression Phar::NONE, Phar::GZ, or Phar::BZ2
3 file extension. Default is <format>.<compression> where .phar.tar is executable .tar
convertToExecutable always returns a Phar object
convertToData always returns a PharData object
also added Phar::PHAR, Phar::TAR, and Phar::ZIP class constants
[DOC]
conversion is now split into 3 separate methods
1\) convertToZip\(\) convertToTar\(\) and convertToPhar\(\) exclusively change file format
2\) compress\(\) sets compression, accepting Phar::GZ, Phar::BZ2, or Phar::NONE
3\) convertToExecutable\(\) allows stub creation in tar/zip, convertToData\(\) prevents it
all methods return either Phar or PharData objects, allowing fluent interface.
only 1 test has been converted to the new format, but the API works
5.3 code expects the proposed patch for stream wrapper in include_path to be committed
5.2 code only supports phar stream wrapper in include_path.
this is a 2-step process. After this, more magic, particularly in funcinterceptors.c will be
converted to use phar_resolve_path, which is far safer than the current implementation.
this needs windows and 5.2 testing unix/windows
- If readonly=0, why not $phardata->convertToPhar()?
- Known issue with directories creating 'as-file' copies within the archive (all formats)
@Greg/Marcus/Tony: This passes all tests on my box, 5.2/5.3/release_ts/debug_ts, and I can't find any more memleaks. Obviously this is too good to be true, so if conversion is still messy elsewhere please feel free to fix, or bug and assign to me.
