Hi Marcus,
Am Freitag, den 28.03.2008, 11:17 +0100 schrieb Marcus Boerger:
[...]
> The above is far too complex. And results in an interface that does not
> make clear what it is doing. Right now we have $phar->offsetSet() with a
> very clear semantics.
Of course I still prefer
$phar->createDirectory("dir")->createFile("foo")->setContent("bar") I
would like to step back and think about how to make the ArrayAccess API
more convenient. The issue I have with ArrayAccess is, that an archive
represents a multidimensional, nested hash. The way Phar works as an
array is doubtful as it represents multi dimensions in a single
dimension hash.
$phar['path/to/file'] instead of $phar['path']['to']['file'], which
would me semantically more correct.
> Maybe what we want to add is getContents() and setContents() to SplFileInfo.
>
> > $phar = new Phar();
> > $phar->add('foo');
> > $phar->add('bar', $data);
> > $phar->add(new SplFileInfo('bar'));
>
> Yet again, unclear. First probable creates an empty entry, same as
> offsetSet('foo', ''); only that one is clear.
No, it will take the content of the file "foo" from the harddisk and
create it as foo. A shortcut to add('foo', file_get_contents('foo')).
> The second one create an entry with content, which is exactly what
> $phar->offsetSet('bar',$data) does.
Yes.
> The third is extremely confusing. What does it do? What will be the
> entry name? And will it just take the entry name and make an emoty entry or
> will it copy the data from the referenced file?
It behaves like the first example, only that it uses an SplFileInfo
object.
> > Creating directories:
> > $phar = new Phar();
> > $dir = $phar->createDirectory('/foo'); // Return PharDirectory object
> > $dir->add(new DirectoryIterator("mydir")); // Adds every file in the
> > directory mydir
> > $dir->add(new RecursiveDirectoryIterator('otherdir')); // Adds every item
> > recursivly
> > $dir->add(new SplFile("foo")); // Adds the file foo
> > $dir->add('bar'); // Adds bar
> > $dir->add('baz', $data)
> > $file = $dir->createFile('bla')
> > $file->setContent($data);
> > $dir2 = $dir->createDirectory('foo');
> > ...
> > $phar->save();
>
> We have a very nice Phar::buildFromIterator() for this kind of
> creation.
OK, didn't know that. I'm not sure if one could not reuse the
add()-method (or offsetSet() if there is no chance of getting rid of the
ArrayAccess API, $phar["dir"] = new DirectoryIterator(...))
> We also do not really care for directories. Maybe that is something worth
> to add, especially the createDirectory() method.
[...]
> > $phar = new Phar();
> > $phar->createDirectory('foo')
> > ->add('foo')
> > ->add(new SplFileInfo('bar'))
> > ->add('baz', $data);
> > $phar->save();
>
> First of all I do not like fluent interfaces at all here. Because it is
> unclear what it does. What is the return value of each of these?
> Is it the Phar object of the PharEntry or whatever object?
createDirectory() returns a phantasy object called PharDirectory,
PharDirectory::add() returns itself. I think it is really readable,
let's go one step further and create a subdirectory
$phar->createDirectory('bla')
->add('file1', 'content')
->add('file2', 'content')
->createDirectory('foo')
->add('file1', 'content')
->add('file2', 'content');
$phar->save();
Creates bla/file1, bla/file2, bla/foo/file1, bla/foo/file2.
[...]
> > About compression:
> > I would prefer to have Phar::setCompression(Phar::GZIP) or something
> > similiar. Or even Phar::setCompressionStrategy(PharCompressionInterface
> > $interface) but I have the feeling that would go too far :-)
>
> Maybe adding Phar::compressAllFiles() would indeed be good. This one could
> easily map to the two exiting functions.
What would compressAllFiles() exactly do? Would there be any ambiguity
with Phar::compress() (if not, why not call it compress)?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
