Exception: attempt to set flags of immutable class entry

[Andy Schmidt]

I will get the above exception. The documentation states that this exception will occur "if OPcache is enabled, and the class entry of class ... is immutable."

The class I am referencing is the standard WordPress
final class WP_Post { ...

I don't know what makes that class "immutable"? My whole use case for UOPZ is to remove the "final" flag:
uopz_flags( \WP_Post::class, '', uopz_flags( \WP_Post::class, '' ) & ~ZEND_ACC_FINAL);
so that I CAN extend the class.

Is the above still a feature with UOPZ (with OPCACHE enabled) at all?
Will UOPZ need to "copy" such items from OPCACHE's shared memory to process memory, to make the feature available again?

I'm only an "application programmer" so I am not able to determine what the "high level" meaning of the abstract "low level" documentation entry and the internal OPCACHE notes are; e.g., how what the practical implications are with respect to PHP classes and UOPZ functions.

[Christoph M. Becker]

"immutable class entries" are a concept which is internal to the engine. It's just that with uopz you may hit that. I'm afraid there's nothing uopz could do to solve that (besides improving the docs). Short of disabling OPcache altogether, it may be possible to exclude the files containing such class definitions from being cached, to have them manipulatable by uopz again.

[Andy Schmidt]

Thanks for the "exclude" hint!
I will definitely try that with the next build, because in this particular case the "final class" in question is very compact and is isolated in a single file.

As far as documentation, I still don't have a clear understanding if "immutable" and "final" have a 1:1 relationship, which would mean that UOPZ feature is effectively dead with 7.4.9+, or how else an application programmer would known in advance that certain types or styles of PHP coding will/will likely "cause" classes to become "immutable", and how else he should structure his code to avoid falling into the "immutable" trap?

[Joe Watkins]

This is not a bug.

A class only becomes immutable when it is stored in shared memory by opcache. Final and immutable are not related concepts.

If someone wants to make some notes about what immutable means in the docs, that'd be good.

[Joe Watkins]

uopz being aware that it is illegal to modify an immutable class forces you to modify your test or configuration. Incompatible would be allowing you to modify the class and forcing you to suffer the consequences.

…

On Wed, 2 Dec 2020 at 21:58, Andy Schmidt ***@***.***> wrote: Thanks for clarifying. So - if I understand correctly, a PHP programmer doesn't have control over OPcache storing things in shared memory, and UOPZ cannot deal with OPcache storing things in shared memory. Consequently, is it a fair statement that, while neither has a bug, UOPZ and OPcache are no longer compatible with one another? Is that something that the UOPZ documentation should emphasize to avoid other people from running into this? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#133 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARB52TX3XEM5HE23J6CIYTSS2S5RANCNFSM4Q3IPQRQ> .

[Andy Schmidt]

That's what I was hoping to learn from all this - HOW does one "modify my test or configuration" if a PHP programmer has no control/knowledge over how/when a class becomes immutable. It's great that there is a message whenever I use uopz_flags to modify a class, but what's the cookbook after that?

So far I've learned that I could exclude the individual PHP file from optimization, by using the PHP.INI option:
opcache.blacklist_filename

Or is there anything else I should be doing instead?

(Thank you again for your patience with this 60 year old idiot who refuses to retire...)