Hi,
Before I say anything, I have just concluded 20 hours of travel and feel
kinda funny, so please take that into consideration :).
Regarding API changes, let's first be clear:
1) Any changes to file creation need to be understood in terms of what
they means. For instance, let's look at:
$phar['full/path/to/file'] = 'hi';
This creates 1 entry "full/path/to/file"
$phar['full']['path']['to']['file'] = 'hi';
This would create 4 entries
full
full/path
full/path/to
full/path/to/file
In addition, this would mean that offsetGet() would have to create a
directory. Why?
$phar['full']['path']['to']['file'] = 'hi' calls offsetGet() with
'full', 'path', and 'to', and offsetSet() only with 'file'.
In other words, the proposed change is much more complex, introduces
magic and counterintuitive behavior inside the extension. For instance,
let's say we have this code:
<?php
$a = $phar['dir'];
$b = $phar['dri']; // typo
?>
if phar.readonly=1, the second line would throw an exception for
attempting to create the directory "dri"
What about this?
<?php
unset($phar['dri']); // dri doesn't exist
?>
The above code would first create the dri directory, and then erase it.
In other words, the proposed syntax is not a good idea.
2) Names must be very carefully considered in relation to existing APIs
and the pre-existing methods.
Phar::create(), for instance, should be named buildFromDirectory() to
match buildFromIterator().
what benefit is there in adding complexity of remembering the Phar::GZ
constant over setCompressedGZ()? We have to think hard about changes
like this.
3) I would like to suggest these changes, and these alone:
* simplify all compression methods, with more consistency of naming
that clearly differentiates between compressing files within an archive,
and compressing the entire archive. This abstract idea is more
important to me than the specific naming, but it should be very easy to do.
* add a zip-style API for adding files/directories, addFile,
addEmptyDir, addFileFromString with the exact method names
* add buildFromDirectory()
* any further suggestions have off-list vetting with the maintainers
of phar for technical issues prior to publicly posting them, so we can
truly work together and present a more polished API suggestion to those
interested in phar on the first try without confusing them. I am *NOT*
proposing we take discussion to private, only that technical issues be
worked out offlist prior to presenting an idea.
Thank you for your patience, I know I am a bit of a hard-ass at times,
but I am genuinely excited about the discussion and creativity that is
going into this.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
