Hey there!
I'm thrilled since this is my first proposal.
I'd like to propose a new visibility schema for classes, based on a explicit
group of namespaces allowed to use the class.
The goal of this proposal is to provide a way to cover from a native
language feature what currently is usually patched using "@internal"
annotations.
If the visibility declaration ("internals" in this example) is present, the
class could only be visible for other classes on the list of the specified
namespaces.
<?php
namespace Vendor\Library\Feature;
final class Foo implements Vendor\Library\InternalInterface internals
Vendor\Library, Partner\VendorBridge
{
}
/// this class will be allowed to use `Vendor\Library\Feature\Foo` because
it is declared directly at `Vendor\Library` namespace
<?php
namespace Vendor\Library;
use Vendor\Library\Feature\Foo;
class Allowed
{
public function __construct()
{
new Foo();
}
}
/// this class will be allowed to use `Vendor\Library\Feature\Foo` because
it one level under `Vendor\Library` namespace
<?php
namespace Vendor\Library\Service;
use Vendor\Library\Feature\Foo;
class Allowed
{
public function __construct()
{
new Foo();
}
}
/// this class will NOT be allowed to use `Vendor\Library\Feature\Foo`,
since the current namespace `Vendor` doesn't match and is not under
`Vendor\Library` nor `Partner\VendorBridge`.
<?php
namespace Vendor;
use Vendor\Library\Feature\Foo;
class Disallowed
{
public function __construct()
{
new Foo();
}
}
I think a good example of the kind of project that can leverage this
feature are the libraries which expose a public API with its own
implementation, but need to protect their internal classes in order to
avoid them to be tied to their BC promise.
Note that I really don't know how to implement this internally, or if this
must be just related to the autoload mechanism instead of a (maybe) more
complex compilation phase.
Please, let me know if you have some concerns or doubts about it.
Thank you in advance.
--
Javier Spagnoletti
