Le 02/11/2015 15:42, guilhermebla...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
