-
Notifications
You must be signed in to change notification settings - Fork 2k
fix: Anonymous class support for ReflectionHelper
#9877
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.7
Are you sure you want to change the base?
Conversation
|
|
||
| $refClass = new ReflectionObject($obj); | ||
|
|
||
| if (! $refClass->hasProperty($property) && str_contains($obj::class, '@anonymous')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you know how duplicate properties should work correctly, you can fix it here. When properties exist in both classes
|
I don't think this is a good idea. Reflection exposes class semantics as they are. Private properties belong strictly to the declaring class. Automatically scanning parent private properties would make private appear inherited, which it is not. The helper would introduce a misleading abstraction, so the current behavior should remain unchanged. |
|
@michalsn In my opinion, if we need access to private properties, are we allowed to change the parent values? |
|
A helper should make common tasks easier, not redefine visibility rules. Parent private properties are not part of the child's API, and Reflection does not change that. |
|
Sadly. Overdoing it again. Let's wait @paulbalandan @samsonasik Do you think it's okay to duplicate private properties in an anonymous class? The parent will not change, only the child. |
|
In this example: // Foo class
$obj->private = 'root';
// anon class with Foo
$child->private = 'child';
// helper will only change the child, the parent will contain the old value
// for example, call from the root method
$child->getPrivate() // rootin my opinion, |
|
Good. This is still a problem if you really need to get a private value. Can we move it to new methods and specify it as 'feat'? |
I'm against this. Mocking private parent state couples tests to implementation details rather than behavior, which is generally a design smell and not something helpers should normalize. |
Description
I'm doing another PR and in the tests I found that anonymous classes cannot access parent properties. I hope this fixes it.
I want to note that there will be problems when both classes have the same properties - the reflection of the helper changes only the child. Any suggestions?
Example:
The guide, as always, corrects the translation.
Checklist: