Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92135
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.82 cause and error)
Reply-To: internals@lists.php.net
References: <56ED495C.80809@fleshgrinder.com>
To: internals@lists.php.net
Message-ID: <57069A72.7030100@fleshgrinder.com>
Date: Thu, 7 Apr 2016 19:35:46 +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: <56ED495C.80809@fleshgrinder.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="6eGML5xr6rmk2OgvQIEqxwOaCjlcaJLxQ"
Subject: Re: [PHP-DEV] Access and Visibility Modifiers
From: php@fleshgrinder.com (Fleshgrinder)

--6eGML5xr6rmk2OgvQIEqxwOaCjlcaJLxQ
Content-Type: multipart/mixed; boundary="cgVKGPKpI8OsjwJgh7ow5C2XqvWF3KvLB"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <57069A72.7030100@fleshgrinder.com>
Subject: Re: [PHP-DEV] Access and Visibility Modifiers
References: <56ED495C.80809@fleshgrinder.com>
In-Reply-To: <56ED495C.80809@fleshgrinder.com>

--cgVKGPKpI8OsjwJgh7ow5C2XqvWF3KvLB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/19/2016 12:51 PM, Fleshgrinder wrote:
> 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 imh=
o
> 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. I=
n
> 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 i=
s
> 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.=
 :)
>

I would like to change above definition for properties since the *var*
deprecation was voted negative:

# Properties
private   :=3D limited to the current class
protected :=3D limited to the current and child classes
var       :=3D limited to the current assembly
public    :=3D global

And here is a list of additional keywords I collected that could be used
instead of *assembly* (which I do not like that much):

- group
- crate (used by Rust)
- unit
- segment
- kit
- container
- bin
- ...

I was also thinking about prescribing some parsable format for the
content of this new keyword. I do not see a real value in doing so since
such an identifier does not bare any meaning other than grouping
namespaces and classes together, hence, we could simply use a string, e.g=
=2E:

     assembly 'WhatEver!';

On the other side, not specifying anything parsable might result in
misuse in the community. An alternative would be to reuse the namespace
syntax. The advantage would be that users do not have to learn a new
syntax. A disadvantage is that is looks very similar to namespaces. A
third option is to use the composer package naming conventions. Yes we
would be pulling in something from a userland tool here but we would
actually just say that composer did something good here and bless it.
The syntax would be:

    assembly <vendor>/<name>;

    /[a-z](?:[_-]?[a-z0-9])*\/[a-z](?:[_-]?[a-z0-9])*/Di

This syntax would be extremely strict compared to the possibilities for
other identifiers in PHP and the PCRE might need to be extended if this
is an option you find worth pursuing.

Would love to here some general feedback on the idea.

--=20
Richard "Fleshgrinder" Fussenegger




--cgVKGPKpI8OsjwJgh7ow5C2XqvWF3KvLB--

--6eGML5xr6rmk2OgvQIEqxwOaCjlcaJLxQ
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

iQIcBAEBCAAGBQJXBppyAAoJEOKkKcqFPVVr1pwP/1S50nE1DfsRod2h6kX6FivG
fq40fIRY3OMtJCEQWF2bUPuMJIqjfCzEcUYV3Hg8s89H5ZXBLBWzS7WYl+8JZgnT
TxBxD0OErK1n8g4gWdLbtSXMcoH2m8xaWkMEGAIeEnlOq+i9nlHB0J6xNXouNX9M
o5RL3ACxhpkubEoKrwg7aNkxSi+0FP8704V3k5Dy3SWLd3oynh9qLL2mi3Gg0Pjf
fTFvEZ9anIAPl4bIWoK6RSfVCH0PuzlmddRBiGS0pzi04c9M5t69OD2e7OlpBG3p
vlzfs6IwwcqwutYa6nuVk7jyjnMA4WRU2VQuDmrBXPg9riaaFz9Wk1QM+J02/9fK
2ADy1Lfoe7EBv+XA+yan1eS7QY66zeGSLLDWGIj4bbTsXqCgO/mEOXnN+LqMGAde
IIM45v6ly/0bBXmD4/wag16zUS8O9W3/7Tz2u/+WM/j5r7ebaH0xtCky9ovxbOqr
k2gzVZPJtWKz+YjY5BLvbTHmTO4Ck5JkQ/EfL86/XBXP3KBlLVMQAgwdKpUo2fSU
sXNTIO2TpI7J3/KJERZl3kUBw1oVA8R0yq3Odgu9tZcA+bVX9ekp2NAjhBU233Su
gERHtf8QA9OL/zkb3lU/hUuiCuc3BT6RkCAB5gGBFJp6zo3OZ/YEEeBN6T3twVaZ
JbukiF3oT9j5AI8sS3HT
=r9Ee
-----END PGP SIGNATURE-----

--6eGML5xr6rmk2OgvQIEqxwOaCjlcaJLxQ--