Re: phar API

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

Attachment: [application/pgp-signature] Dies ist ein digital signierter Nachrichtenteil signature.asc