Replies: 2 comments
-
I think it makes sense to raise on shadow when the shadow is owned by the same class, but a really valid use of shadowing is to override a property from a super class. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I’d be up for looking at a PR, but I’m going to close this issue as I don’t think it’s something we need to do and issues to me represent TODOs. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
A thought: how about adding an optional (as in configuration) raise if a prop reader/writer shadows an existing instance method on definition? Eg
Obviously shadowing is always a possibility but thinking about when literal properties are used in library code where the end-user dev must inherit from some base and then add props, we can offer guard against accidentally shadowing base methods?
Beta Was this translation helpful? Give feedback.
All reactions