Friend class/function

Andrea Faulds wrote on 01/11/2015 19:35:

I recently wished PHP had this feature when trying to implement the
Khronos Group Typed Arrays specification in PHP, which requires sharing
certain data between unrelated (inheritance-wise) classes. I ended up
having to expose a public method to get the data, but named in a way that
was likely to deter use.

Would "package" (namespace-based) visibility have solved the problem in
this case? That's something I've often wanted - "this is public within this
Lib, but should never be used outside it".

This was worked on for 7, but had a fundamental problem blocking it - See
Guilherme's recent runtime execution scope mail.

Hi Rowan,

Rowan Collins wrote:

Andrea Faulds wrote on 01/11/2015 19:35:

I recently wished PHP had this feature when trying to implement the
Khronos Group Typed Arrays specification in PHP, which requires
sharing certain data between unrelated (inheritance-wise) classes. I
ended up having to expose a public method to get the data, but named
in a way that was likely to deter use.

Would "package" (namespace-based) visibility have solved the problem in
this case? That's something I've often wanted - "this is public within
this Lib, but should never be used outside it".

Yep, that would have worked, and that sounds like a much cleaner
solution. Package/namespace visibility would solve a bunch of other
use-cases too.

Thanks!

--
Andrea Faulds
http://ajf.me/

​One more detail : I wouldn't set the 'friend' information on the same
line as the class declaration.

I agree, it can look horrible to read, and the way to use the "friend"
syntax as the way that we currently "use" traits can be an interesting idea.

Geolim4

2015-11-02 15:42 GMT+01:00 guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com>:

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.

Regards,

Hi Georges,

Le 01/11/2015 17:04, georges a écrit :

​Hi php internals,

I recently discovered ​the "friendship concept" in c++ and i really love
the concept.
And i wonder if the php internals would be interested to implements it in
the next 7.x major version.

You may be interested by an article I wrote some weeks ago about adapting
the 'friendship' concept to PHP (
http://tekwire.net/joomla/projects/ideas/php-friend). IMO, we should
enable friendship from classes and/or namespaces, with and without
inheritance, giving four cases : class, class and descendants, namespace,
namespace and sub-namespaces.

One more detail : I wouldn't set the 'friend' information on the same
line as the class declaration. First reason is that it already contains
'extends' and 'implements' stances. 2nd reason is that the information is
not required by the compiler to start compiling the class body. So,
'friend' lines can be part of the class body.

Use cases go well beyond test classes. There are many cases where you
need to access methods and/or even whole classes from a set of known
locations, but don't want to make them public. Today, the only way is to
use protected access but it implies class inheritance which, often, is not
an option. An example is symfony using the '@internal' tag to mark
class/properties/methods which mustn't be accessed from the outside of
symfony (see
http://symfony.com/doc/current/contributing/code/bc.html#using-our-classes).
Information is better than nothing but a way to enforce access restrictions
would be welcome.

About Guilherme's proposal : it seems fine but, IMHO, the 'friend'
concept includes it, is easier to implement, and goes much further.

Regards

François

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