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
-
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