Hi Elizabeth,
Am Freitag, den 28.03.2008, 12:12 -0500 schrieb Elizabeth M Smith:
[...]
> I'd vote for Phar::canWrite() && is_writable('test.phar') - so you know
> if you actually can change the phar.
OK, fine. That's how I have it in the proposal too, and Marcus already
stated his preference the same way.
[...]
> After looking over the rfc - the phar as a multidimensional array, the
> isWriteable, the createDirectory and the Phar::create would solve most
> of my current API gripes for phar - the rest...I don't know what
> rewriting all the splfileobject and splfileinfo methods would achieve...
PharFileInfo is derived from SplFileInfo. Therefore adding
setContent()/getContent() to SplFileInfo would allow doing
setContent()/getContent() with PharFileInfo. Phar is derived from
DirectoryIterator and DirectoryIterator allows to set the info class
(setInfoClass(), the info class must be derived from SplFileInfo).
SplFileObject is derived from SplFileInfo, therefore renaming the would
make the usage of SplFileObject more straighforward, if a user does the
following:
$phar = new Phar("test.phar");
$phar->setInfoClass('SplFileObject');
$file = $phar['file']; // File would be an instance of SplFileObject
> The only things I see missing are an addFile and addDirectory shortcut
> methods for when I don't want to mess with all the metadata or creating
> iterators.
addDirectory() is called createDirectory() in my RFC, just ignore the
return value. What would you like addFile() to do? Adding an empty file?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
