Re: Unsetting declared fields

On Mon, Jan 16, 2017 at 9:49 AM, Michał Brzuchalski <michal@brzuchalski.com> wrote: > Hi Marco, > > 2017-01-16 0:27 GMT+01:00 Marco Pivetta <ocramius@gmail.com>: > >> Hi Wes, >> >> This has been discussed before, and it's currently used to intercept >> access >> to properties. Since we don't have property accessors (sigh), the code >> (simplified version) would look like following: >> >> class Foo >> { >> public $bar = 'baz'; >> } >> >> class FooInterceptor extends Foo >> { >> private $wrapped; >> public function __construct(Foo $wrapped) >> { >> $this->wrapped = $wrapped; >> unset($this->bar); >> } >> public function __get(string $name) >> { >> var_dump('reading ' . $name); >> return $this->wrapped->$name; >> } >> } >> >> $foo = new FooInterceptor(new Foo); >> >> var_dump($foo->bar); >> >> You can see a working example at https://3v4l.org/UtugD > > > There is one more thing might be confusing - reflection tells there still > exists bar property after unset while it's realy not. > For example https://3v4l.org/NAg1l > > $class = new ReflectionClass(FooInterceptor::class); > $property = $class->getProperty('bar'); > var_dump($property); // still exists while actually being unset may cause > errors > > I'm sticking to extending class without magic _get method implemented. > > >> >> >> This behavior is protected from regressions since PHP 5.4, but has been >> working since 5.0: >> >> https://github.com/php/php-src/blob/cd2b462a2742c79256668d47 >> 36644e34573c33d9/tests/classes/unset_properties.phpt >> >> We can most probably get rid of this weird behavior once property >> accessors >> are in the language. >> >> Greets, >> >> Marco Pivetta >> >> http://twitter.com/Ocramius >> >> http://ocramius.github.com/ >> >> On Mon, Jan 16, 2017 at 12:20 AM, Wes <netmo.php@gmail.com> wrote: >> >> > Hello elephpants. >> > >> > Currently PHP allows explicitly declared fields (eg public $foo = 10;) >> to >> > be removed entirely through unset (eg unset($obj->foo)). >> > >> > Now that isn't really an issue as properties in php are currently >> untyped >> > and therefore nullable; at worst you would get a notice. But it would >> > become an issue with typed fields... that might get a second chance >> sooner >> > or later. >> > >> > But regardless of that, it looks very strange to me that this is allowed >> > for fields that are explicitly declared. I think unset() should set the >> > field to null if it's declared in the class, and remove the field >> > altogether only if it was defined dynamically. >> > >> > On the other hand, this is just one of many ways of hacking php that >> just >> > exist and we accept / don't care because we have faith in other people >> not >> > doing nasty stuff with our code. This might sound ironic it is actually >> not >> > :P >> > >> > However, I am curious: what you think about this? Should PHP do >> something >> > in regard? Should this continue to work like it does now? Why do you >> feel >> > it should do the one or the other? >> > >> > Hi Michał, Reflection will also trigger __get in this scenario, which is expected and was also reverted multiple times in "fixes" that worked around or forgot to call the property access guards. class Foo { public $bar = 'baz'; } class FooInterceptor extends Foo { private $wrapped; public function __construct(Foo $wrapped) { $this->wrapped = $wrapped; unset($this->bar); } public function __get(string $name) { var_dump('reading ' . $name); return $this->wrapped->$name; } } $foo = new FooInterceptor(new Foo); $reflectionFooBar = new \ReflectionProperty(Foo::class, 'bar'); var_dump($reflectionFooBar->getValue($foo)); See https://3v4l.org/6JtWT for a working example. You can see https://github.com/Ocramius/ProxyManager/tree/cce5477857504997baf3168974b8f1283516a686/tests/language-feature-scripts for As I already mentioned, this hack is currently necessary to make property access interception transparent, which is common for most AOP-oriented code. We need an alternate approach to make this happen, before such a feature can be dropped. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/