Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36671
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: php-dev <internals@lists.php.net>
Cc: Elizabeth Smith <emsmith@elizabethmariesmith.com>,
  Greg Beaver <greg@chiaraquartet.net>
In-Reply-To: <47ED6D97.3030109@chiaraquartet.net>
References: <47ED6D97.3030109@chiaraquartet.net>
Date: Sat, 29 Mar 2008 12:02:57 +0100
Message-ID: <1206788577.3621.15.camel@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_milch.schokokeks.org-20251-1206788579-0001-2"
Subject: Re: [PHP-DEV] practical phar considerations
From: lars@strojny.net (Lars Strojny)

--=_milch.schokokeks.org-20251-1206788579-0001-2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Greg,

Am Freitag, den 28.03.2008, 17:13 -0500 schrieb Greg Beaver:
[...]
> In addition, this would mean that offsetGet() would have to create a=20
> directory.  Why?
>=20
> $phar['full']['path']['to']['file'] =3D 'hi' calls offsetGet() with=20
> 'full', 'path', and 'to', and offsetSet() only with 'file'.

I know that and I discussed that with Marcus beforehand. I don't think
that implicitly creating the directory is much an issue. If somebody
does not want that, he can just use isset() before.

> In other words, the proposed change is much more complex, introduces=20
> magic and counterintuitive behavior inside the extension.  For instance,=20
> let's say we have this code:
>=20
> <?php
> $a =3D $phar['dir'];
> $b =3D $phar['dri']; // typo
> ?>
>=20
> if phar.readonly=3D1, the second line would throw an exception for=20
> attempting to create the directory "dri"

Wouldn't the second line throw an exeception anyway because the index is
not defined? And: can't offsetGet() check weither Phar::canWrite() is
true?

> What about this?
>=20
> <?php
> unset($phar['dri']); // dri doesn't exist
> ?>
>=20
> The above code would first create the dri directory, and then erase it.

No, it would not. Please take a look at
http://lars.schokokeks.org/php/phar.phps and
http://lars.schokokeks.org/php/phar.php

> In other words, the proposed syntax is not a good idea.

Two of three assumptions were not correct or at least arguable, so I
can't agree that easily.

> 2) Names must be very carefully considered in relation to existing APIs=20
> and the pre-existing methods.
>=20
> Phar::create(), for instance, should be named buildFromDirectory() to=20
> match buildFromIterator().

I agree, that this name is much better.

> what benefit is there in adding complexity of remembering the Phar::GZ=20
> constant over setCompressedGZ()?  We have to think hard about changes=20
> like this.

setCompressedGZ() is just not the way object oriented APIs should
behave, as it taints the API with concrete implementation details
("there can be gzip compression and every compression algorithm is
exposed" opposed to "there can be compression, one variant is gzip").
Phar::compress() indicates that "the archive can be compressed" with the
concrete algorithm as a parameter. What about in 5 years when a new,
free compression algorithm rises, which fixes the problems of bzip2.
Would you like to add another setCompressedFooBar() or just add the
algorithm and the class constant and be fine?
If you insist on setCompressedFoo(), I would at least propose to not
implement that as a setter but to describe the attached behaviour, which
would be Phar::compressWithGzip() or something like that. Nevertheless,
please seriously consider to do it with a single compress()-method.

> 3) I would like to suggest these changes, and these alone:
>=20
>   * simplify all compression methods, with more consistency of naming=20
> that clearly differentiates between compressing files within an archive,=20
> and compressing the entire archive.  This abstract idea is more=20
> important to me than the specific naming, but it should be very easy to d=
o.

What would be your concrete proposal regarding that?
[...]

cu, Lars

--=_milch.schokokeks.org-20251-1206788579-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)

iQIcBAABAgAGBQJH7iHVAAoJECQPF+sCY6wHo/YP/RI2XN/gmPOV9GiyOmsKdrXC
lK/T7iAmg5rHLfyumpAGZIo5XjmwxgDa3+qRaAZ7c4oN668DWNjiLNQjF6oCrybv
0J/iZ8UgAVXYHI/gBEKnchb4hjtLt9SGZVBq/d0+Qy7btABVs/ZhcQk6g8uI9K8j
Iwk6ivSC19pn5Z9C9OBH9McGFWOFCnQA+7Ca/aD1gHFNGBkyiBsl/ZFkJ5TKF/OF
zmCogahaBLlSR8hPjAmMyWZN81ijg6dXy7asz3JGDjcUISfYhMPIZzkujRv0r4+T
e3vUzBw1BjIj/s/6N/GuW0dXrag2jClnMFz+yZXdb6uxHIPVUR+Y6YV4P8uyumsB
3LOAolYKgTExGGyHQl5dPviumBVufYebK8N7CL5YpTg4/fV3TxzNmLgMZrYoIIQS
L2GvTWNHE7ELvcKlhNNu68EZU807epiPzphaTtCQimVNd1Paxt8+EgqNET+N+rco
g75aOVfuE40tkTPzK5Yvcjwac14XH2CLW5ZLRE/JguUfgjH7y8ahUPBelILPGguc
46A3FFT9yMsCX2KAG0IuTpR+HVU7qBuKxZ7mqFskUqV0WMJJXVOFBzZ8Q3i4PI8T
z5HQZUZiFZAI7WS2bkA1MHioiLw8b6oQbkFR8TsLSbBo6wbDHQ8rJvRndKtzCVUg
akTUw6fVsqrmro68Cqp3
=oEEJ
-----END PGP SIGNATURE-----

--=_milch.schokokeks.org-20251-1206788579-0001-2--