Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38746
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain strojny.net designates 78.46.69.2 as permitted sender)
To: Travis Swicegood <tswicegood@php.net>
Cc: php-dev List <internals@lists.php.net>
In-Reply-To: <4C2C6BC2-4DD3-443A-A411-C6B0AFA80058@php.net>
References: <1215076043.7021.10.camel@localhost>
	 <4C2C6BC2-4DD3-443A-A411-C6B0AFA80058@php.net>
Date: Fri, 04 Jul 2008 09:53:36 +0200
Message-ID: <1215158016.8875.8.camel@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_milch.schokokeks.org-3050-1215158016-0001-2"
Subject: Re: [PHP-DEV] [RFC] Namespaces for internal classes
From: lars@strojny.net (Lars Strojny)

--=_milch.schokokeks.org-3050-1215158016-0001-2
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Travis,

Am Donnerstag, den 03.07.2008, 16:31 -0500 schrieb Travis Swicegood:
>=20
> * Completely bike shedding, but does "Recursive" need its own level?
> RecursiveArray reads better than having Array at two different levels
> to me.

Alright, I will change that.

> * Again, bike shedding, but I like the name ArrayIterator - it =20
> defines exactly what the class is while Array doesn't convey very =20
> well by itself.  You have to look at the full name in order to =20
> understand the process.  This also becomes ambiguous when you're =20
> reading the code in PHP.  What does "$a =3D new Array($some_array);" =20
> do?

That's what "use" is for. You would do "use Spl::Iterator::Array as
ArrayIterator" and than "new Array" becomes "new ArrayIterator" which is
pretty clear. Of course, we should add that to the docs if we go that
way.

> You end up with more verbose names by going to a PEAR1 style of =20
> naming convention because you have to use the entire name with the =20
> namespace in order to convey what the code is supposed to be doing.  =20
> I would stick with names more closely related to the original names =20
> and add "spl::" (see next comment for lowerspace) to signify that =20
> they're part of SPL.  So instead of RecursiveArrayIterator, you have =20
> spl::RecursiveArrayIterator; SplFileInfo becomes spl::FileInfo, etc.

I see it more as packages. "Spl" is a package consisting of several
subpackages like "Iterator", "Lists", etc. pp.

> * I would change everything except the final class name in the full =20
> name to be lowercase.  Using your existing examples:  =20
> Spl::List::DoublyLinked would be spl::list::DoublyLinked, or better =20
> yet spl::DoublyLinkedList, etc.  This helps denote what is a class =20
> and what is part of the namespace name.  In the original examples, =20
> its ambiguous as to what can be instantiated.  Are Spl and Spl::List =20
> classes that can be instantiated?  Moving to the lower space =20
> convention makes it easy to denote what is a class and what is just =20
> part of the namespace.  This follows the path created by several =20
> other languages.

I don't really have an argument against that, except that I honestly
don't like it, sorry :). I'm not sure how I could assume that
"Spl::List" can be instantiated, as I miss the hint that it exists. If
Spl::List is a problem, everybody out there must have a hard time trying
to figure out that there is no StringIterator because ArrayIterator
exists?

cu, Lars

--=_milch.schokokeks.org-3050-1215158016-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)

iQIcBAABAgAGBQJIbdcAAAoJECQPF+sCY6wHG/cQAIjiZ4yiXOf5my0ApOEqISVN
z6dp2m0G7XhP+aJhhqGpVcoWDsAnwMgJNGVTTmeW5GNCQBoOJhA2I9za9/DLy/MV
2RaVuQpwLK97WwECLQw8ysyYvrvQpAEvNKniMaumHfElTZzdMT8ZziwPzEbfW5lS
Jic0OGbjA304OqUickTYLDMI8W/zRCfn61Xvm0oVnn0P7zrsSTTILZv5tSlxiSAp
1ZQbIKTLgjU9TYh4HPmun1rIOYiItLpxgSIWbOpLVz7xxfjy4B59kMRFPhrpxYhX
HltnZapKS1hEtsrg+SVeuC6/qV1TsGI9X29XptdZyzi4SfSiNl3lBPckYrP5WzX9
c+hewv3rrdcfScOSdl1MhybcDPHj1VBj51Km8Eo7ZfCemiHjmV+mw+o5v1y6Yf7e
k0Dx0DkM6OoQG3ELP84TSaeYGsA23AjVLeLdXuBe95vYhOAtfWTvh7MHw8xT585C
20WY+Wie49/NhQl+TNHQlbqZko745WeU8jKksp9toE9LMTC2ydwkoAJvVYZXp0xL
bF11uf81PdJwyryGoBvJWt/op4r29FekHol4VtWGqXESYL1JWqWMFSpSLbNjwuAm
wJ2CWqq6FEP9LAX1SOAH0jhfd1UA3VLuGvUql1V2EjGIB4nlCFgLGfyyOQ5GykYP
JrFIPaGRrYGjA0yUWG/9
=Z6s9
-----END PGP SIGNATURE-----

--=_milch.schokokeks.org-3050-1215158016-0001-2--