Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109367
MIME-Version: 1.0
References: <CAHSyNszP7GJg2-RV=0zPNrQyvbk1wX3efs3=O09_Fpk9W0KYnA@mail.gmail.com>
In-Reply-To: <CAHSyNszP7GJg2-RV=0zPNrQyvbk1wX3efs3=O09_Fpk9W0KYnA@mail.gmail.com>
Date: Thu, 26 Mar 2020 20:47:12 -0300
Message-ID: <CAHSyNsyZ4pn2fVBVZe+saj3zntZ=+K2+8FQpj740WyZbtRxRtQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000044711705a1ca9ba1"
Subject: Fwd: Intended proposal for class visibility
From: phansys@gmail.com (Javier Spagnoletti)

--00000000000044711705a1ca9ba1
Content-Type: text/plain; charset="UTF-8"

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

--00000000000044711705a1ca9ba1--