-
-
Notifications
You must be signed in to change notification settings - Fork 575
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
Make sure _get
and _set
dispatch up the class hierarchy
#1539
Make sure _get
and _set
dispatch up the class hierarchy
#1539
Conversation
f3d5629
to
904c2f4
Compare
Thanks!
Yeah, if we can align with in-engine modules, I'm all for it. However, I think this still doesn't completely match the behavior in modules. Looking in if (m_inherits::_setv(p_name, p_property)) { \
return true; \
} \
if (m_class::_get_set() != m_inherits::_get_set()) { \
return _set(p_name, p_property); \
} \
return false; \ Which looks like it tries the parent first, and then if the parent doesn't have that property, it tries the child. Whereas the changes in this PR have it try the child first, and if it doesn't have that property, it tries the parent. |
904c2f4
to
9d5a5ab
Compare
9d5a5ab
to
c77d44f
Compare
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.
Thanks! This looks good to me :-)
Cherry-picked for 4.2 in PR #1570 |
Cherry-picked for 4.1 in PR #1572 |
@dsnopek this is in response to my question from chat. It seems a bit odd to me that
_get_property_list
dispatches up the class hierarchy while calls to_get
and_set
do not and expect the developer to call the super type internally. I'm not sure whether we want to alter this behavior or leave it as-is and document this nuance for others who may prefer to use these override methods for property management.This change also seems to align the GDExtension behavior with C++ modules, too.