Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115869
MIME-Version: 1.0
In-Reply-To: <CAJpLVh2w_6eroEZeiPxNwqwBB8cuBNqoME6Lr9PcwvXwPb5HfQ@mail.gmail.com>
References: <CAJpLVh37mrtQhBWgviWi+gJV6w=yVR4VRwqp=vdu5tZB_e+D+w@mail.gmail.com>
 <ace949e6-8160-50b2-52ca-410832c0aeec@gmail.com> <CAJpLVh2w_6eroEZeiPxNwqwBB8cuBNqoME6Lr9PcwvXwPb5HfQ@mail.gmail.com>
Date: Thu, 26 Aug 2021 22:27:15 +0200
Message-ID: <CAJpLVh24iHkH3-f5YNz4LqfZi4xatUMQOx4d94vzLkRqACJc5w@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Alternatives for encapsulation when using composition
 instead of inheritance
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2021-08-26 22:20 GMT+02:00, Olle H=C3=A4rstedt <olleharstedt@gmail.com>:
> 2021-08-26 20:30 GMT+02:00, Rowan Tommins <rowan.collins@gmail.com>:
>> On 26/08/2021 14:47, Olle H=C3=A4rstedt wrote:
>>> Don't know if this already exists, but maybe we could consider
>>> brainstorming or gather alternatives for different types of
>>> encapsulation when using composition?
>>
>>
>> Although not quite equivalent to your suggestions, these threads on
>> making delegation to an encapsulated object might be interesting to you:
>>
>> *  https://externals.io/message/103353
>> * https://github.com/php/php-src/pull/5168
>
> Right, there are indeed a bunch of attempts and suggestions, some
> downvoted, others abandoned.
>
> I'm thinking adding namespaces to runtime might be a logical first
> step. That would allow attributes to add logic like internal
> properties for a certain namespace. Makes me wonder why that never
> happened for this PR: https://github.com/php/php-src/pull/947
>
> Asking anyone on the list, would it be possible to make an opcode out
> of "namespace Foo\Bar" and letting it set a flag in the runtime system
> when run? Then make the flag accessible with a constant like
> __NAMESPACE_RUNTIME__ or whatever.
>
> Ooooh, there's an interesting case with "goto" and namespace
> visibility here:
> https://github.com/php/php-src/pull/947#issuecomment-419821198
>
> That would mean every zval has to carry in which namespace it was
> defined inside. I wonder how that would affect the memory footprint of
> PHP.
>
>> If we had something like that, then perhaps there could be a
>> "delegatable" visibility, which was the equivalent for "protected", but
>> when delegating rather than inheriting, e.g.
>>
>> class Foo {
>>      private int $a =3D 1;
>>      delegatable int $b =3D 2;
>> }
>>
>> class Bar {
>>      private delegate Foo $foo;
>>      public function __construct(Foo $foo) {
>>          $this->foo =3D $foo;
>>          echo $this->a; // Error: can't access private property of a
>> different class
>>          echo $this->b; // allowed: access is to a "delegatable"
>> property, in a "delegated" context
>>      }
>> }
>
> The Foo class has to decide who to give access to, otherwise it's the
> same as public access.
>
> Olle

Whops, Nikic already answered this in 2016:

> The goto here will jump from code in namespace A to code in namespace B w=
ithout "directly" crossing the boundary. For this reason just inserting opc=
odes when a namespace starts or ends will quite cut it.

https://github.com/php/php-src/pull/947#issuecomment-224934615

So, deprecate goto when...?

Olle