Hi,

I was working on a private-class support for PHP an year ago, until I hit a
problem I couldn't fix myself.

Hi, I know and I commented on the PR on GitHub some time ago. I kept the
semantics of private classes exactly as you have implemented it in there.

The situation that brought me to work on this is, as a library developer,
people reuse internal classes that are not meant to be reused outside of
library's code. Changes to its API can potentially break consumers of the
library, making upgrades hard to happen.

That is exactly my motivation as well.

To mitigate this problem, I thought about working on two patches to the
language that could help library/application developers, self-containing
code that is not meant to be reused. They're detailed as follow:

1- Private-class visibility: Only classes in the same namespace (siblings)
or child ones could instantiate the class. Cloning would still be possible
outside of namespace's scope, the same to access public members.
This is what is currently 90% done in:
https://github.com/php/php-src/pull/947
It requires changes to Zend Engine to include a start namespace and an end
namespace opcodes, allowing to locate in which scope you are. There are
failing tests that are not passing because of this right now.

2- Protected-class visibility: It would work the same way as private-class
visibility, but with the difference that other classes in the same
namespace/child namespaces could access protected members of the specified
protected class.

Of course both of them would require to go through RFC writing, idea
validation, voting and performance assessment process, but it's already a
start.

All fine with the private class approach and as mentioned I kept it
equal. However, the protected class approach you describe has a huge
drawback: it does not apply to parent namespaces. This makes it
extremely hard to organize the classes nicely, e.g. (symfony/process):

namespace Process\Pipes {

    abstract private class AbstractPipes {}

    final protected class UnixPipes extends AbstractPipes {}

    final protected class WinPipes extends AbstractPipes {}

}

namespace Process {

    final public class Process {}

}

Where the process instantiates the pipes as needed.

Another problem is that suddenly every class in the current and child
namespaces have the ability to access protected properties. However, you
might not want that because protected properties are for true childs
only. Hence, we need an additional modifier that currently does not
exist in order to have full control over the usage of our internals.

This is what I tried to achieve with my proposal, cover the logical side
of things so that we can retrofit it to PHP without any kind of BC.

Richard "Fleshgrinder" Fussenegger

In other words: same as Java without any modifier. I only changed the
proposal because var is to be kept and the current semantic of it
(implicit public) but not being truly equal motivated me to change the
proposal and to give it a new meaning.

That is hard to decipher, let me rephrase:

The vote to deprecate and drop var was negative:

https://wiki.php.net/rfc/var_deprecation

This means that we are going to keep it with its current semantic:
implicit public. However, var is currently not truly the same as
public as outlined in the RFC above. My proposal would fix that problem.

--
Richard "Fleshgrinder" Fussenegger

Meanwhile, it might be worth checking the list archives for previous
discussions of package visibility; I know it has come up a couple of
times recently, in various forms, so it would be good not to repeat the
same points again and again.

I check what I can dig up. :)

Here we go:

2007-12: Namespace access modifiers

http://marc.info/?t=119750415000002

2009-09: New access modifier

http://marc.info/?l=php-internals&m=125341032112627

Some nice keyword suggestions in this one:

• group
• trusted
• party

2011-03: Class Access Modifiers

http://marc.info/?t=129917302700001

2013-02: I would like to write an RFC for the addition of an internal

keyword
http://marc.info/?t=136194893000003

2014-12: Package private class

http://marc.info/?t=141929489300003

2015-11: Internal methods proposal

http://marc.info/?t=144836744000001

I am sure that I overlooked something since the search turned up a lot
of stuff. However, the above list already illustrates that such a
feature is often requested and useful. This is further illustrated by
other languages providing similar functionality.

There were various questions raised in the threads above that I would
like and try to answer here.

Can child classes redeclare visibility or override it.

Yes, every class in an inheritance change can open up the visibility as
is already the case for methods in PHP. The reason for that is simple:

namespace Process\Pipes {

    public interface Pipes {}

    abstract private class AbstractPipes implements Pipes {}

    protected final class UnixPipes extends AbstractPipes {}

    protected final class WinPipes extends AbstractPipes {}

}

The UnixPipes and WinPipes classes are useless if they cannot open up
the visibility because they cannot be instantiated from nowhere.

It would still be possible to get an instance of a private class from
the outside, e.g.:

namespace Internals {
    private class Foo {}
    public class Bar {}
        public function getFoo() {
            return new Foo();
        }
    }

}

Yes and this is intentional. The class visibility modifiers only
restrict the creation of such objects and not the interaction with them
at runtime. Otherwise it would be impossible to implement a public
interface in a private class that is being returned to the client.

public interface Entities extends \IteratorAggregate {}

public interface EntityManager extends Entities {}

private class InMemoryEntities implements EntityManager {}
private class FilesystemEntities implements EntityManager {}
private class MySqlEntities implements EntityManager {}
private class PdoEntities implements EntityManager {}

switch (ENV) {
    case PROD:
        $entities = new MySqlEntities;
        break;

    case TEST:
        $entities = new InMemoryEntities;
        break;
}

$dic->addService('entities', $entities, [
    'alias' => 'entitye_manager',
]);

This is not /good code/ or anything but should illustrate the usefulness
of it. In other words:

It supports the I in SOLID. :)

https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

--
Richard "Fleshgrinder" Fussenegger