Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92144
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.83 cause and error)
Reply-To: internals@lists.php.net
References: <56ED495C.80809@fleshgrinder.com>
 <57069A72.7030100@fleshgrinder.com> <5706A182.6080401@gmail.com>
 <CAFp73XssJqErBRzi=Y4W4oppfw57pAwqYz-QZF11xsjjZygn9g@mail.gmail.com>
To: internals@lists.php.net
Message-ID: <5706AE7A.2030004@fleshgrinder.com>
Date: Thu, 7 Apr 2016 21:01:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAFp73XssJqErBRzi=Y4W4oppfw57pAwqYz-QZF11xsjjZygn9g@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="mRFAFUfrFCbXmbrRpSawnaBVC1E70oSmM"
Subject: Re: [PHP-DEV] Access and Visibility Modifiers
From: php@fleshgrinder.com (Fleshgrinder)

--mRFAFUfrFCbXmbrRpSawnaBVC1E70oSmM
Content-Type: multipart/mixed; boundary="ATKRUmHG2O5dAxVVW1uMP730TSfBR35Tj"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <5706AE7A.2030004@fleshgrinder.com>
Subject: Re: [PHP-DEV] Access and Visibility Modifiers
References: <56ED495C.80809@fleshgrinder.com>
 <57069A72.7030100@fleshgrinder.com> <5706A182.6080401@gmail.com>
 <CAFp73XssJqErBRzi=Y4W4oppfw57pAwqYz-QZF11xsjjZygn9g@mail.gmail.com>
In-Reply-To: <CAFp73XssJqErBRzi=Y4W4oppfw57pAwqYz-QZF11xsjjZygn9g@mail.gmail.com>

--ATKRUmHG2O5dAxVVW1uMP730TSfBR35Tj
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 4/7/2016 8:32 PM, guilhermeblanco@gmail.com wrote:
> Hi,
>=20
> I was working on a private-class support for PHP an year ago, until I h=
it a
> problem I couldn't fix myself.
>

Hi, I know and I commented on the PR on GitHub some time ago. I kept the
semantics of private classes exactly as you have implemented it in there.=


On 4/7/2016 8:32 PM, guilhermeblanco@gmail.com wrote:
> The situation that brought me to work on this is, as a library develope=
r,
> people reuse internal classes that are not meant to be reused outside o=
f
> library's code. Changes to its API can potentially break consumers of t=
he
> library, making upgrades hard to happen.
>

That is exactly my motivation as well.

On 4/7/2016 8:32 PM, guilhermeblanco@gmail.com wrote:
> To mitigate this problem, I thought about working on two patches to the=

> language that could help library/application developers, self-containin=
g
> code that is not meant to be reused. They're detailed as follow:
>=20
> 1- Private-class visibility: Only classes in the same namespace (siblin=
gs)
> or child ones could instantiate the class. Cloning would still be possi=
ble
> outside of namespace's scope, the same to access public members.
> This is what is currently 90% done in:
> https://github.com/php/php-src/pull/947
> It requires changes to Zend Engine to include a start namespace and an =
end
> namespace opcodes, allowing to locate in which scope you are. There are=

> failing tests that are not passing because of this right now.
>=20
> 2- Protected-class visibility: It would work the same way as private-cl=
ass
> visibility, but with the difference that other classes in the same
> namespace/child namespaces could access protected members of the specif=
ied
> protected class.
>=20
> Of course both of them would require to go through RFC writing, idea
> validation, voting and performance assessment process, but it's already=
 a
> start.
>=20

All fine with the private class approach and as mentioned I kept it
equal. However, the protected class approach you describe has a huge
drawback: it does not apply to parent namespaces. This makes it
extremely hard to organize the classes nicely, e.g. (symfony/process):

    namespace Process\Pipes {

        abstract private class AbstractPipes {}

        final protected class UnixPipes extends AbstractPipes {}

        final protected class WinPipes extends AbstractPipes {}

    }

    namespace Process {

        final public class Process {}

    }

Where the process instantiates the pipes as needed.

Another problem is that suddenly every class in the current and child
namespaces have the ability to access protected properties. However, you
might not want that because protected properties are for true childs
only. Hence, we need an additional modifier that currently does not
exist in order to have full control over the usage of our internals.

This is what I tried to achieve with my proposal, cover the logical side
of things so that we can retrofit it to PHP without any kind of BC.
--=20
Richard "Fleshgrinder" Fussenegger


--ATKRUmHG2O5dAxVVW1uMP730TSfBR35Tj--

--mRFAFUfrFCbXmbrRpSawnaBVC1E70oSmM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXBq5+AAoJEOKkKcqFPVVr2AEQAIvJcUNry+omHwKeC7TnV2J3
60A7aKLxWQcLT9FOAB4GZMq+JEsZv3JBU3PFWrFVZm91cRffRqWby22sCUa7Sa5c
Og3Aw7acRew4i4ruUcXhZFn36LWQhECKxMCrEjMrOqhvUyicUFu5Xp72yEW9l414
K26qE3zn0PZBv48lZdOz7zkDSMY6ajB6e28BckAvX9lIJAJV1Gj0EMFbuTIIYb0I
e4jUR4H19pkiJyP2BuKGNsy4GeiiqQxQDwO+S/3KuzgmK0YVFCKbFb/OjxgwNxxj
y6wD8oON4ONM8f3vjjMY+4LGyVXqscSXTm9Huqg/KON+ZYF0b/5lfDwaSvc9Q0qJ
WtMFA3Lrf8X36c+7yZ01VQuo1GEhvm7iJGC/09KdswbbaxMVA0qHCJe0+ud38XMH
A3AE5J1oW9oxl7B4DkjwYB/CzNlFb0+HDwPFjXFFbr0EdSDkaUh5ToEbffQtjJbh
qe3bce7EOqI5NdXdSSJtU+OCRXaqUOks/9O3WvTydX8IHFuC7gjALYRzSWar7skC
fY48K1wXrIZgnKnhX5sSJeKJVBxi6tXxiCnmPiQhOrNU7HOmfyraGvesmSnFmuBW
SZ9+DfARfEsMfT/mHcpeWd8sqZP48waGtFQ3uNN9yymGjY+V8ZsCV21LqRQe8dFM
4zD61naQ8RQouI3UDWbz
=O+Hu
-----END PGP SIGNATURE-----

--mRFAFUfrFCbXmbrRpSawnaBVC1E70oSmM--