2

I'm working with a 3rd party composer library that doesn't currently support PHP 8.2 and trying to add compatibility to my application.

The 3rd party package has the following classes:

class Configuration { }
class ApiClient extends Configuration { }

I then have another extension:

class MyApiClient extends ApiClient { }

I am receiving the following error:

[E_DEPRECATED] Creation of dynamic property MyApiClient::$propertyName is deprecated

The fix is supposed to be adding #[AllowDynamicProperties], however this isn't actually doing anything.

I have the following:

#[AllowDynamicProperties]
class MyApiClient extends ApiClient { }

And still receive the deprecation error.

I have even edited the underlying library files, to end up with the following:

#[AllowDynamicProperties]
class Configuration { }

#[AllowDynamicProperties]
class ApiClient extends Configuration { }

#[AllowDynamicProperties]
class MyApiClient extends ApiClient { }

And yet the deprecation error persists.

I'm at a bit of a loss as I can see no reason the attributes wouldn't be taking effect. What am I missing? I'm definitely editing the right files, and if I define the properties inside MyApiClient the deprecation error goes away.

Edit:

As a clearer example as one is seemingly needed:

class Configuration
{
    public function __construct()
    {
        $this->propertyName = 'foo';
    }
}

class ApiClient extends Configuration { }

class MyApiClient extends ApiClient { }

Error: [E_DEPRECATED] Creation of dynamic property MyApiClient::$propertyName is deprecated

Expected fix is to add #[AllowDynamicProperties]:

class Configuration
{
    public function __construct()
    {
        $this->propertyName = 'foo';
    }
}

class ApiClient extends Configuration { }

#[AllowDynamicProperties]
class MyApiClient extends ApiClient { }

However, even with this attribute, the deprecation error persists.

Error: [E_DEPRECATED] Creation of dynamic property MyApiClient::$propertyName is deprecated

Even when the underlying composer library files are manually edited (which I cannot do as a long term fix) it does not work:

#[AllowDynamicProperties]
class Configuration
{
    public function __construct()
    {
        $this->propertyName = 'foo';
    }
}

#[AllowDynamicProperties]
class ApiClient extends Configuration { }

#[AllowDynamicProperties]
class MyApiClient extends ApiClient { }

Error: [E_DEPRECATED] Creation of dynamic property MyApiClient::$propertyName is deprecated

The only way to resolve the error is to define the property:

class MyApiClient extends ApiClient
{
    public $propertyName;
}

However, this should not be necessary.

MattRogowski
  • 726
  • 2
  • 7
  • 22
  • 2
    Why not just declare the properties in the class definition, instead of adding them dynamically? – Barmar Jan 03 '23 at 20:36
  • Please add the exemplary line(s) of code that provoke the error to your question, this would help to clarify the problem. Also please reduce the problem in the question (like what is commonly asked for with the [mre]), it should be possible that you'll be able to create the problem with a single class and no third-party library as you create that impression with your question. Proof it beforehand. Asking != Guessing. Please [edit]. – hakre Jan 03 '23 at 20:37
  • Because as stated it's a 3rd party library, thus I don't have access to do that in the base class, and it shouldn't be necessary to do it in the class extension as it's what `#[AllowDynamicProperties]` is supposed to do. – MattRogowski Jan 03 '23 at 20:38
  • _"thus I don't have access to do that in the base class"_ - your question suggests to me that you actually were able to access the base class: _"I have even edited the underlying library files, to end up with the following:"_ - this is a puzzling way to _ask_ about something. – hakre Jan 03 '23 at 20:40
  • I edited the base class to confirm it was not an issue with my extended class, it is obviously not possible to edit composer packages as a long term solution. – MattRogowski Jan 03 '23 at 20:42
  • Yes, but your question suggests that _regardless_ of editing the base class the deprecation diagnostic message persists, which marks the attribute _as flawed_. If that is the case, editing the base-class (or not being able to do so) renders out of question. – hakre Jan 03 '23 at 20:48
  • I simply included that to avoid suggestions that my class was not extending the base class properly, which I had ruled out by editing the base class itself. I have edited to include a clearer example. – MattRogowski Jan 03 '23 at 20:50
  • Well, you may wanted to avoid so, but honestly, the example you give is not reproducible: https://3v4l.org/757K1 --- therefore please clarify in your question what you ask about and provide a [mre], otherwise it is just not clear what your problem is. The attribute works as documented first of all. So how may we help you? – hakre Jan 03 '23 at 21:01
  • The problem is that within the application and using the 3rd party package directly, it is not working. I physically cannot provide a fully reproducible example without providing a several-thousand file project and database - not everything can be reproduced in a handful of lines unfortunately. The example above documents the behaviour I'm seeing, so trying to ascertain what could be causing it. – MattRogowski Jan 03 '23 at 21:05
  • You may have a different problem, the attribute _only_ on the extending class suffices: https://3v4l.org/2ShJO – hakre Jan 03 '23 at 21:16

1 Answers1

4

The issue is namespaces - I was unaware Attributes were scoped to the current namespace or that namespaces would have any relevance.

So:

#[AllowDynamicProperties]
class MyApiClient extends ApiClient { }

Needs to be:

#[\AllowDynamicProperties]
class MyApiClient extends ApiClient { }

Alternatively:

use AllowDynamicProperties;

#[AllowDynamicProperties]
class MyApiClient extends ApiClient { }

Without this, usage of the Attribute fails silently.

MattRogowski
  • 726
  • 2
  • 7
  • 22