Re: Alternatives for encapsulation when using composition instead of inheritance

2021-08-26 22:20 GMT+02:00, Olle Härstedt <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ärstedt 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 = 1; >> delegatable int $b = 2; >> } >> >> class Bar { >> private delegate Foo $foo; >> public function __construct(Foo $foo) { >> $this->foo = $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 without > "directly" crossing the boundary. For this reason just inserting opcodes 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