Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115877
MIME-Version: 1.0
References: <CAJpLVh37mrtQhBWgviWi+gJV6w=yVR4VRwqp=vdu5tZB_e+D+w@mail.gmail.com>
 <ace949e6-8160-50b2-52ca-410832c0aeec@gmail.com> <CAJpLVh2w_6eroEZeiPxNwqwBB8cuBNqoME6Lr9PcwvXwPb5HfQ@mail.gmail.com>
 <6ABFB65D-6F8E-4591-B36A-EA4B4CEC96A5@gmail.com>
In-Reply-To: <6ABFB65D-6F8E-4591-B36A-EA4B4CEC96A5@gmail.com>
Date: Fri, 27 Aug 2021 08:55:44 +0300
Message-ID: <CAAwdEzC1CA0XT_aj3+EE+mnYE6aCecKYg-k8FrwZL649t=8DVA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>, =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004f671405ca8423ac"
Subject: Re: [PHP-DEV] Alternatives for encapsulation when using composition
 instead of inheritance
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000004f671405ca8423ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 27, 2021 at 12:53 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 26 August 2021 21:20:35 BST, "Olle H=C3=A4rstedt" <olleharstedt@gmail.=
com>
> wrote:
> >The Foo class has to decide who to give access to, otherwise it's the
> >same as public access.
>
>
> It does decide who has access: any class that declares it as "delegated".
> In exactly the same way, "protected" gives access to any class that
> declares it as a "parent", and namespace visibility would give access to
> any class that declares itself in the same namespace.
>
> None of those actually limit access to a named list of classes, but all o=
f
> them document an intended use, and catch mistakes where that intent isn't
> followed.
>

Well I wouldn't say they're quite the same. You can definitely limit the
usages more with the "private" keyword. Or with declaring the class "final"
for "protected" visibility, not allowing a "parent".
I think something along these lines was asked. To have a way to decide the
limitation by the original library, not by the one that decides to use it.

Now... I also think that we might not necessarily need this.
So far it looks like @internal works well enough.
If a library is marking a class or method with @internal, it means it is
not part of the public API and they might change it in the future.

Static tool analysis like phpstan and psalm produce errors for using it.
Also editors will warn you if you are using it.
For all purposes you should treat it as private.

If we really want the PHP runtime to produce a warning/error, even if this
check makes sense mostly statically, we can think about a similar metadata
with attributes with something like
#[PackageInternal(namespacePrefix: 'Acme\Foo')]
that can be applied to methods, classes and even properties and would
trigger those warnings/errors when used from another namespace.

This leaves the decision point on the library authors, not on the users of
it.

Regards,
Alex


>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000004f671405ca8423ac--