Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36644
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain strojny.net designates 85.10.204.248 as permitted sender)
To: Marcus Boerger <helly@php.net>
Cc: Benjamin Schulz <php@benjaminschulz.com>,
  internals Mailing List <internals@lists.php.net>
In-Reply-To: <26719276.20080328111709@marcus-boerger.de>
References: <DA010320-E879-42BB-87BE-243CA34CBFE0@benjaminschulz.com>
	 <1206626878.7434.56.camel@localhost>
	 <26719276.20080328111709@marcus-boerger.de>
Date: Fri, 28 Mar 2008 13:22:31 +0100
Message-ID: <1206706951.6331.24.camel@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_milch.schokokeks.org-23270-1206706952-0001-2"
Subject: Re: [PHP-DEV] phar API
From: lars@strojny.net (Lars Strojny)

--=_milch.schokokeks.org-23270-1206706952-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
=EF=BB=BF
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 SplFileIn=
fo.
>=20
> > $phar =3D new Phar();
> > $phar->add('foo');
> > $phar->add('bar', $data);
> > $phar->add(new SplFileInfo('bar'));
>=20
> Yet again, unclear. First probable creates an empty entry, same as
> offsetSet('foo', ''); only that one is clear.=20

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.=20

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 =3D new Phar();
> > $dir =3D $phar->createDirectory('/foo'); // Return PharDirectory object
> > $dir->add(new DirectoryIterator("mydir")); // Adds every file in the di=
rectory mydir
> > $dir->add(new RecursiveDirectoryIterator('otherdir')); // Adds every it=
em recursivly
> > $dir->add(new SplFile("foo")); // Adds the file foo
> > $dir->add('bar'); // Adds bar
> > $dir->add('baz', $data)
> > $file =3D $dir->createFile('bla')
> > $file->setContent($data);
> > $dir2 =3D $dir->createDirectory('foo');
> > ...
> > $phar->save();
>=20
> 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"] =3D new DirectoryIterator(...))

> We also do not really care for directories. Maybe that is something worth
> to add, especially the createDirectory() method.
[...]
> > $phar =3D new Phar();
> > $phar->createDirectory('foo')
> >    ->add('foo')
> >    ->add(new SplFileInfo('bar'))
> >    ->add('baz', $data);
> > $phar->save();
>=20
> 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 :-)
>=20
> Maybe adding Phar::compressAllFiles() would indeed be good. This one coul=
d
> 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

--=_milch.schokokeks.org-23270-1206706952-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iQIcBAABAgAGBQJH7OMHAAoJECQPF+sCY6wHUqUP/RFkq6BTdx9k3ZD9Xyo9rDhw
uUodK0nUMGmhv8/U+wRfYWmdGe4ihPV0D/YN1L8/7mY2bsbCiSlDafrTkjSWvbnb
qZuung+1FjkcrJtWp9vTTf2QH3rvJyATKgwshz86/u3HTPl7g2ghEA0MD4fm0kAe
vNNhK1NhLGpXp2VFnBJFHNPK2d3l0A3qdKucMILJg39wA7DjgOB+kD6YCJ60hJut
suD+WiRptpVNb3hFq8hokT/8bD6dWZomhK2Zde6GznMhN0tjGdAbTZMadQzNAzB7
UKTWTI9X8yqTzAd00jGOYFdi/uzVtePdKvO5sUKvZ4J/z8QNvD88UwIFZ/yIDRqx
97ET8HwSzATLrqSIbYr1vZl1FelYpGE/bZ169Z9eEKzWoj71fAHXbTK/9i7MZ+QK
qIpMPFIDZuofIBywY+B8cztwpUOpXzDV84h4L1EpXm6JAfLk1MdnOeRqAfLOqSF+
HUYYtbaYrK5K3KLQeKDrN15X0GteC3DgBLi3zxjg7gqh5+CJzHHhY8Z25BXxb1j9
igKEqpNuAESpoilxFF2FdL23ZENjDixE0cPMAUpxV++1mAteysGd+2ZtBIj26CJ7
Gp7ngXSMR0ExxpdmjfcHuXFaraHbc3i0I+r/qDx5tQ8JZEkcBYFH/iP9QLvLOYGc
7/4vc6mmj3un92vX5jsj
=YIGL
-----END PGP SIGNATURE-----

--=_milch.schokokeks.org-23270-1206706952-0001-2--