Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.162 cause and error)
Reply-To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56E9CC3E.10205@telia.com> <56E9D45D.4060309@fleshgrinder.com>
 <CAEPJdum+BiXj9Y0o288y1VjopMBnDeDSHmMeHHRQqPXpOMmjsw@mail.gmail.com>
 <56EC611F.7050601@fleshgrinder.com> <56ED2C1C.3090902@telia.com>
 <56ED2E94.5050902@fleshgrinder.com>
To: internals@lists.php.net, =?UTF-8?Q?Bj=c3=b6rn_Larsson?=
 <bjorn.x.larsson@telia.com>
Message-ID: <56ED3D29.90709@fleshgrinder.com>
Date: Sat, 19 Mar 2016 12:51:05 +0100
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: <56ED2E94.5050902@fleshgrinder.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="IoRWl3bNIq3niG4WmNE48vSb65ab13g3w"
Subject: Access and Visibility Modifiers
From: php@fleshgrinder.com (Fleshgrinder)

--IoRWl3bNIq3niG4WmNE48vSb65ab13g3w
Content-Type: multipart/mixed; boundary="SRQ1kmSoGnuSF5AaMMBbpTE0itSX3hm2t"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net, =?UTF-8?Q?Bj=c3=b6rn_Larsson?=
 <bjorn.x.larsson@telia.com>
Message-ID: <56ED3D29.90709@fleshgrinder.com>
Subject: Access and Visibility Modifiers
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56E9CC3E.10205@telia.com> <56E9D45D.4060309@fleshgrinder.com>
 <CAEPJdum+BiXj9Y0o288y1VjopMBnDeDSHmMeHHRQqPXpOMmjsw@mail.gmail.com>
 <56EC611F.7050601@fleshgrinder.com> <56ED2C1C.3090902@telia.com>
 <56ED2E94.5050902@fleshgrinder.com>
In-Reply-To: <56ED2E94.5050902@fleshgrinder.com>

--SRQ1kmSoGnuSF5AaMMBbpTE0itSX3hm2t
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Moving this to a new thread in order to not spam the other.

On 3/19/2016 11:48 AM, Fleshgrinder wrote:
> On 3/19/2016 11:38 AM, Bj=C3=B6rn Larsson wrote:
>> Den 2016-03-18 kl. 21:12, skrev Fleshgrinder:
>>> No worries you are not, not at all. I just wanted to thwart you and
>>> others in directly assigning ...
>>>
>>>      final class A {
>>>          int $x;
>>>      }
>>>
>>> ... to be *public* and obstruct the opportunity of assigning it a
>>> meaningful new functionality.
>>>
>> Well, but if one should assign int $x without visibility keyword a
>> meaning, shouldn't it be the same as for function y() {} without
>> keyword, i.e. public?
>>
>> Of course one can change both, but that sounds like a 8.0 topic.
>>
>> Regards //Bj=C3=B6rn
>>
>>
>=20
> It is a sad state the implicit public properties use *var* and implicit=

> public methods nothing, this makes the introduction of new visibility
> modifiers terribly complicated. You are completely right, they should b=
e
> the same and *var* should be banned. It is consistent and that is very
> important. I cannot and do not want to argue against this. Yet at the
> same time the lack of access (and additional visibility) modifiers is
> what I am missing the most. Seems as if this has to wait for 8.0 (or
> 9.0, depending on the resistance). :(
>=20

I just thought about this some more and this is actually not true.

    namespace Fleshgrinder\Examples\PhpInternals;

    final class A {
        int $x;
        var $y;
        $z;

        function getX() {
            return $this->x;
        }
    }

Everything is public here, as we already agreed upon and changing that
would be a topic for 8.0 or 9.0. The *var* keyword should be banned imho
but I do not know about the *$z* in the example. Is this even possible
with the parser? Otherwise we could keep the *var* keyword because with
my proposal here it would become useful again.

    assembly fleshgrinder/experiments;

    namespace Fleshgrinder\Examples\PhpInternals;

    final class A {
        int $x;

        function getX() {
            return $this->x;
        }
    }

Where *assembly* could also be *module*, *package*, ... and it allows
one to group multiple classes and namespaces together across composer
packages. Furthermore it alters the access and visibility of members. In
the above example where no visibility modifiers are specified both the
class /A/ and the method /getX/ are only accessible within the
*fleshgrinder/experiments* assembly. This approach would allow the
introduction of such a system in a feature release (7.x.0) without
breaking changes. Either the new keyword is present and missing
visibility modifiers are globally scoped (hence implicit public) due to
everything being in the global assembly by default or the new keyword is
present and missing visibility modifiers are restricting access to the
assembly.

Usage of the word /package/ could be a blessing and a curse at the same
time because the word is already heavily in use in the PHP world, e.g.
/@package/ in DocBlocks or in /composer package/.

The same holds true for /module/ because it is sometimes used to refer
to PHP extensions and PEAR uses it.

Hence, *assembly* might be the best choice here and is my proposal.

The following proposal in regards to access and visibility is not well
thought through but hopefully a starting point:

# Methods
private   :=3D limited to the current class
protected :=3D limited to the current and child classes
          :=3D limited to the current assembly
public    :=3D global

# Properties
private   :=3D limited to the current class
protected :=3D limited to the current and child classes
          :=3D limited to the current assembly
public    :=3D global
var       :=3D E_STRICT or limited to the current assembly

# Classes, Interfaces, and Traits
private   :=3D limited to the current namespace
protected :=3D limited to the current and child namespaces
          :=3D limited to the current assembly
public    :=3D global

Default assembly is always global and old code would not change at all. :=
)

--=20
Richard "Fleshgrinder" Fussenegger


--SRQ1kmSoGnuSF5AaMMBbpTE0itSX3hm2t--

--IoRWl3bNIq3niG4WmNE48vSb65ab13g3w
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

iQIcBAEBCAAGBQJW7T0tAAoJEOKkKcqFPVVrNrwQAKrOzqpFgPqsisZt1/1XyDAn
puSLlPDqlkPOcSfJvCHQgBFO0j61vNHbh4a0f3zEq5TqYxZpdgBa0Gbfk4EOTeOu
TvLZQqBTGmzpvC95C6cEmBu0TDdSaXkaiVwOY04VVVaz+6BprWPUwIVGsj41T8jx
+BTyGUkcKqAq8nvXhDezDxewSgIqF8H5a2w/CogzV5aPQyzrdwZL7XhzmEhn0wLQ
zdpM6na+Xv+hP0fYIVlWJoYSoe9ihpXop9Ki9AlG1DXsYTsXVyV6+lSKWKLSlFDe
5fTx8vyjH9/C6CjiA0JsC80qgojh5wwjhtqw2TzLKNpNHLKepHU2J99O3lxtbXNJ
THf6lx+tx9vwbIoJzRa9093eNujXvsIn2G0d13ubQogyKr4Dhrpc33JzylSe8llX
3wZZ/kM2gPdNInPM5nHxe0EDHxvuZn449b6HBNRftwwt0n6f+2J6TfGvCJdYI6Ji
4v21uRsbZJRB8r5k5Cdq3UfRUuTu7GGjWvLCiSUSig8ZdnBtEu8n4s2WigyK5S67
mX0g379Eje3FdqlIHNBImr/cVOE4gjkfLT9qndmYb/vQK8A9eBL4b0vxzksKXoUS
ChtYIjKiQd75sQzWGDaJV5soclUddUnHL4Kna+Svo4hqL6ZcCYxTi6F+IBiVFR63
KH190R/Lc4dm8M9n0gNQ
=ULUY
-----END PGP SIGNATURE-----

--IoRWl3bNIq3niG4WmNE48vSb65ab13g3w--