Hi Greg,
Am Samstag, den 29.03.2008, 17:58 -0500 schrieb Greg Beaver:
[...]
> If one uses file_put_contents('/path/to/this/file', 'hi') and
> '/path/to/this' does not exist, there is an error. The same is true of
> fopen, regardless of mode. mkdir() even fails unless the recursive
> parameter is explicitly specified. I do not think that this behavior
> should be different in ext/phar, especially because all that is needed
> is to create 1 directory (full/path/to/) and add the file.
I mostly agree. Except that the whole argument chain applies to the
current API. You mentioned mkdir("foo/bar/baz") triggering an error
without the recursive argument, but Phar['foo/bar/baz'] does not.
[... Performance concerns ...]
> $phar['long/path/to/subdir/file'] = 'hi';
>
> compared to:
>
> $phar['long']['path']['to']['subdir']['file'] = 'hi';
>
> is significantly slower. Each [] results in a call to offsetGet and
> instantiation of a new PharFileInfo object plus the final offsetSet call.
Could you estimate how hard that performance hit would be?
[....]
> Yes, but if you're attempting to access the "dir" directory, an
> intuitive exception would be "dri not found" instead of "write access is
> disabled, cannot create dri directory." If I got the write access
> error, I would report a bug, since I was not trying to write anything.
The exception message would be far away from being optimal, yes.
[...]
> Only 1 was incorrect, but my objection still holds on a fundamental
> level: offsetGet() should not attempt to write anything.
>
> However, let's examine the feature from another perspective - I think it
> could be useful as a read access method, for several reasons:
>
> 1) foreach($phar as $name => $file)
>
> This construct does not iterate over every file in the phar archive, but
> instead iterates over only those files in the top-most directory. If a
> directory returned implemented ArrayAccess and Iterator, one could treat
> it like a phar object. Currently this isn't possible. This means
> ultimately one should be able to do:
[... Code snippets ... ]
I would like that, yes.
> 2) Some might find it easier to do something like:
>
> $phar['subdir/with/really/long/path/file1.txt'] = 'a';
> $subdir = $phar['subdir/with/really/long/path'];
> $subdir['file2.txt'] = 'a';
> $subdir['file3.txt'] = 'a';
>
> Incidentally, if you want to know a *real* hack in the implementation of
> ArrayAccess, you can make a directory now with this code:
>
> $phar['subdir/with/really/long/path/'] = 0;
>
> Needless to say, that probably should be removed as an option :).
Yes, this shouldn't be allowed while
$phar['foo/bar/baz'] = new DirectoryIterator(); could be allowed.
> Could you live with $phar['this']['thing'] as a read access API
> (offsetGet only)?
I'm not sure if I would vote for a partial solution. I think - also I
really do think the current ArrayAccess API is cluttered - it is as
least consistent, which is a plus.
[...]
> As I was trying to say in the portion you quoted below, Phar::compress()
> is already used to compress the entire archive, and should not be
> overloaded. I would be happy with these method names:
>
> Phar::compressArchive() /* Steph hated this when I originally proposed
> it, perhaps she's changed her mind? */
I like it. And much better, it does not contain the compression
format :-)
> Phar::compressAllFiles()
Wouldn't compressFiles() be fine?
> Phar::uncompressArchive()
> Phar::uncompressAllFiles()
Same here, maybe uncompressFiles()
> If I need to explain what the two methods do, then we need to choose new
> names, could you react to these names and let me know what you think
> they would do?
compressAllFiles()/uncompressAllFiles(): compress all the files
contained in the archive
compressArchive()/uncompressArchive(): Compress the archive
[...]
> Lars, I also think it might help to understand my reaction better that
> we've been publicly discussing the API of compression and other
> phar-related issues on pecl-dev for a while, with no feedback.
I would not care so much for phar, if it's inclusion in core has not
been targeted.
> To suddenly see an RFC with major changes without having even been notified
> was annoying, I hope that in the future you will at least contact the
> leads of the project you are proposing changes for so that minor
> disagreements can be worked out in private.
On http://pecl.php.net/package/phar Marcus is listed as one of the two
project leads. I've talked to him *before* writing the RFC on friday. So
this accusation fizzles out. I sort of understand your irritation, but
from my point of view improvement takes place constantly. In the time
Phar was discussed on pecl-dev I was not subscribed to it, now I am. So
the next time I will come up earlier most presumably.
[...]
> Do you want to take a crack at a patch for any of these API features
> once they are worked out (buildFromDirectory should be an easy one, if
> you would like to start there)?
Yes, I'm willing to help with it to a degree, as I said in a previous
mail.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
