Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89045
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
References: <CACjyb+z3Aenebqe4Q5_=VP2Wbs31KwTZhs_Ts-PAHDDraGoALQ@mail.gmail.com>
 <5637540E.3070005@php.net>
 <CAFp73Xs3b5ETNnj1mUi6+RbaGc7vU_aHkCa0PHDUy7Y+B6r_EQ@mail.gmail.com>
Cc: georges <geolim4@gmail.com>, PHP internals <internals@lists.php.net>
Message-ID: <5637A1CE.7070605@php.net>
Date: Mon, 2 Nov 2015 18:47:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAFp73Xs3b5ETNnj1mUi6+RbaGc7vU_aHkCa0PHDUy7Y+B6r_EQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Friend class/function
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)


Le 02/11/2015 15:42, guilhermeblanco@gmail.com a écrit :
>
> Hi,
>
> One thing that should be worth mentioning is that my approach of 
> private classes is decoupled in 2 parts.
>
> The first one as the ability to prevent instantiation outside of 
> namespace and sub-namespaces. The second is the ability to access 
> protected members, which matches your wish of friend classes nicely.
>
> However, I could not even tackle the second part without discussing 
> and agreeing on the first one, so I limited the scope of my wish in 
> order to simplify overall RFC phase.
>

If I understand well, in a second step, you plan to extend access 
control to protected class members. But it will still be reserved to the 
current namespace and sub-namespaces. What I want to implement is the 
possibility to authorize access from *any* class/namespace I want, not 
only the current namespace.

I may be wrong, but I consider restricting access to the currrent 
namespace as sometimes too rigid, sometimes too permissive. Too rigid 
when, in some existing codebase, I want to authorize access from outside 
of the current namespace. Too permissive when I want to authorize only a 
pair of classes in the current namespace. 'Package-private' does not 
provide this flexibility, even if extended to protected members.

Another argument : Imagine you have authorized protected access to 
'private' classes from the current namespace. It will happen only in 
classes marked as 'private'. So, you will end up with cases where access 
to a method is refused because the class was not marked 'private'. In 
the case of instantiation, 'private' brings a restriction, which seems 
fine. In the case of protected access, 'private' will enable some 
additional access, which seems weird, IMO.

Here is a possible syntax for an equivalent of 'package-private' :

class Foo
{
friend __NAMESPACE__\+;

protected function __construct(...)    // Access from current namespace 
and sub-spaces only
{
...

Another concept I was thinking about is to define several 'friendship' 
types in a single class. This would allow a better access control at the 
property/method level. Example:

class Foo
{
friend current_ns __NAMESPACE__\+;
friend purge_enabled \MyNS\bar;

protected(current_ns) function __construct(...)    // Access from 
current namespace and sub-spaces only
{
     ...
}

protected(purge_enabled) function purge(...) // Can be called from 
\MyNS\bar class only
{
     ...

Combined with a future separated read/write access permission to 
properties, this could provide some very precise access control.

Regards

François