Remove XFAIL from sibling method call test

[mvorisek]

I belive the XFAIL is not needed. Method defined in shared parent class MUST be accessible even if redeclared in sibling class.

[cmb69]

This isn't about calling a protected (static) method in the parent class, but rather in a sibling class:

  graph TD;
      A-->B1;
      A-->B2;

Loading

Should B2 be allowed to call protected (static) methods of B1? There was some discussion about this topic many years ago, but apparently, that lead nowhere.

[bwoebi]

I think, this being long-standing behaviour, we should reach consensus to not consider that a bug, but a feature.

As such, I support removing this XAFIL.

The justification for this behaviour should be that the sibling class' static should be considered an override in the parents scope (given that static methods are also subject to inheritance / LSP, they are guaranteed to be compatible).

I.e. a caller of the siblings function can know with certainty that a compatible Sibling::f() exists if the parent has a f() which he can see and thus should be allowed to rely on it and call it on the Sibling.

Basically, visibility does not hide things which are known to exist, but it decides whether things are known at all. Given that the parent already makes the function known, the visibility of the child is irrelevant.

[cmb69]

@bwoebi, I tend to agree (and your reasoning basically matches Stas's).

[mvorisek]

@cmb69 yes :), I updated the title and improved the tests to test calls to sibling method /w and /wo definition in a parent class.

Yes, this is the only consistent way to satisfy LSP, if shared parent has some interface, the interface must be simply available.

[ramsey]

Is there a reason this targets PHP-8.0? Shouldn't it target master instead?

[mvorisek]

Is there a reason this targets PHP-8.0? Shouldn't it target master instead?

it removes 2 XFAILs from PHP 8.0/8.1 CI and asserts the current behaviour as it is correct (explained/discussed above)

[nikic]

This is fine for master. The tested behavior is consistent with prototype inheritance rules. (Our actual implementation is not entirely correct due to a bi-directional inheritance check, but this behavior is not being tested here.)