See https://3v4l.org/9BipO

Note: bug was discovered in builds of ProxyManager at https://travis-ci.org/Ocramius/ProxyManager/jobs/128480921#L384

Bug seems to really only affect reflection access: https://3v4l.org/GY4NC

To summarize OTR discussion:

The issue is that ReflectionProperty::getValue() currently performs a "silenced read", which is roughly equivalent to doing isset($obj->prop) ? $obj->prop : NULL. Prior to PHP 7.0.6 the isset($obj->prop) part did not result in a call to __isset() due to a bug in the magic method implementation.

However, it can be be argued that ReflectionProperty::getValue() should not be performing a silenced read in the first place. It should simply return the value of $obj->prop. If we make this change then the behavior described in the bug report will go back to what it was. On the other hand, this means that using ReflectionProperty::getValue() to read an undefined property will throw an undefined property notice (currently suppressed: https://3v4l.org/vdOjh).

The current plan is to change ReflectionProperty::getValue() to perform the read without silencing.

As per discussion with NikiC and bwoebi in http://chat.stackoverflow.com/transcript/message/30402977#30402977

There has been an ever-living bug in `ReflectionProperty#getValue()` that causes the reflection property to be read (and return `NULL`) even when not set, and that without causing a warning. That can be seen at https://3v4l.org/vdOjh

Code below as reference:

```php
<?php

class Foo
{
    public $bar;
}

$instance = new Foo;

unset($instance->bar);

var_dump((new ReflectionProperty(Foo::class, 'bar'))->getValue($instance));
```

This code always returns `NULL`, but it should raise a NOTICE.

PHP 7.0.6 somehow mitigates the bug by doing an implicit `isset()` check internally, but that changes behavior of `ReflectionProperty#getValue()` in such a way that it breaks some userland existing code ( https://github.com/Ocramius/ProxyManager/issues/306 - possibly also other codebases) by causing `__isset` calls.

Making `ReflectionProperty#getValue()` trigger a notice when a property IS_UNDEF could probably be a good solution.

Looks good from here! Related tests seem to pass on 7.0.7-DEV

:beer:

it's actually a weird coincidence that it was you who submitted the bug. The fix is actually causing a regression in Doctrine now:

https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHP70-720/test/case/30048596

because:

object(ReflectionProperty)#201 (2) {
  ["name"]=>
  string(7) "country"
  ["class"]=>
  string(33) "Doctrine\Tests\Models\Cache\State"
}

and getValue() is called with a Doctrine\Tests\Models\Cache\City entity.

PHP 5.6 doesn't complain, whereas PHP-7.0 current does:

"Undefined property: Doctrine\Tests\Models\Cache\City::$country"

I'll leave it up to you guys to decide what to do ;)

Saw that failure in my mailbox, thought it was unrelated.

As far as I can remember, doctrine only unsets `public` properties and uses a reflection workaround to access them (https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Reflection/RuntimePublicReflectionProperty.php), so something else is going on there.

I'll test against the latest PHP-7.0 ASAP

@mbeccati this seems to be a failure on doctrine's side. I traced it down, and it seems like:

 * `Doctrine\Tests\Models\Cache\City#$state` is not defined (property doesn't exist)
 * `new ReflectionProperty(\Doctrine\Tests\Models\Cache\State::class, 'country')` is used as reflection property (wrong class)
 * PHP doesn't seem to check that the instance passed to `getValue()` respects the original interface ( see https://3v4l.org/0EAZe ), and that causes the code to fail with a notice rather than with something like a `ReflectionException`

I will open a new issue about this.

Findings moved to  https://bugs.php.net/bug.php?id=72209&thanks=4

Closing, moved remaining bits to https://bugs.php.net/bug.php?id=72209