Properties (property hooks) composition

[SerafimArts]

Description

There is code that implements behavior other than method declarations:

Methods Behaviour

<?php

trait ExpectsFooMethod
{
    abstract public function foo(): string;
}

trait ProvidesFooMethod
{
    use ExpectsFooMethod;

    public function foo(): string {}
}

final readonly class FooMethodImpl
{
    use ProvidesFooMethod;
}

Methods Result

See: https://3v4l.org/O5lIe#v8.4.6

// Nothing: OK

Properties Behaviour

<?php

trait ExpectsFooProperty
{
    abstract public string $foo { get; }
}

trait ProvidesFooProperty
{
    use ExpectsFooProperty;

    public readonly string $foo;
}

final readonly class FooPropertyImpl
{
    use ProvidesFooProperty;
}

Properties Result

See: https://3v4l.org/tM9i5#v8.4.6

Fatal error: ProvidesFooProperty and ExpectsFooProperty define the same hooked property ($foo) in the composition of ProvidesFooProperty. Conflict resolution between hooked properties is currently not supported. Class was composed in xxxx.php

PHP Version

PHP 8.4.5 (linux, windows); PHP 8.4.6 (from 3v4l.org)

Operating System

Windows, Ubuntu 20.04, Ubuntu 22.04

[iluuu1994]

Hi @SerafimArts. As the message says:

Conflict resolution between hooked properties is currently not supported.

Conflict resolution of hooks in traits (meaning, declaring the same property in both trait and target, at least one of them with hooks) is not supported. This was explicitly mentioned in the RFC:

https://wiki.php.net/rfc/property-hooks#interaction_with_traits

Properties in traits may declare hooks, just like any other property. However, as with normal properties, there is no conflict resolution mechanism provided the way methods have. If a trait and a class where it is used both declare the same property with hooks, an error is issued.

Hence, this is not a bug, and changing it would likely require an RFC.

[SerafimArts]

From the user's point of view, there is only one declaration in the code. An abstract property declaration is not a declaration, but a requirement for a declaration. Moreover, the implementation is already defined as a readonly field, not a property (hook).

This leaves us with 2 problems (mistakes?):

• The error message relies on the implementation, not the actual code:
  • Reports that the property is being overwritten by the property, however, in the code there is an abstract property that is implemented through a readonly field (there is no rewriting, semantically).
• The RFC also relies on the implementation, not the declared behavior:
  • Perhaps the implementation of this functionality simply did not provide for the abstract properties and they are simply considered in the same way as the implementation, leaving this functionality for future improvements (as stated in the RFC).

[SerafimArts]

P.S. I do not argue that it does not work correctly. It just seems that this functionality can be implemented without RFC in 8.5, since semantically (depending on the RFC interpretation), fixing this behavior falls within the scope of this same RFC. Since "technically" there are no real property declarations in code above

[castletheperson]

The error is deceiving. There's no "conflict" that needs to be resolved here, because there's only one implementation that's ever given for the property in the class hierarchy.

Here's a better example to illustrate the issue:

<?php

abstract class A {
    abstract public int $foo { get; }
}

trait T {
    public int $foo { get => 42; }
}

final class B extends A {
    use T;
}

Output:

Fatal error: A and T define the same hooked property ($foo) in the composition of B. Conflict resolution between hooked properties is currently not supported.

<?php

interface A {
    public int $foo { get; }
}

trait T {
    public int $foo { get => 42; }
}

final class B implements A {
    use T;
}

Output:

// No issues!

For some reason there's a different behavior when the abstract property hook is declared in an interface rather than an abstract class. Traits should always be able to provide implementations for abstract property hooks when there's no other implementation in the target use site. This does not conflict with what was said in the RFC. If it does, then why does it work with interfaces?

[iluuu1994]

Your examples are fixed on master (8.5) by #15878.

https://3v4l.org/O5lIe/rfc#vgit.master
https://3v4l.org/Uor8U/rfc#vgit.master

A backport would be too risky, so closing this accordingly.