-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
drop use of unsupported_reason_add #255
Conversation
The |
# TODO: are these overridden? | ||
# TODO: can we just focus on the unsupported_reason? | ||
# TODO: can we just use supports_not :instantiate instead of using these methods? |
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.
@kbrock I think we should keep this method for now since we override it in some scenarios but we could drop it in the future
Can you drop the TODO comments?
78eb2e8
to
0e97a0e
Compare
update:
|
Checked commit kbrock@0e97a0e with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint |
@agrare I see that we added
instantiate_supported?
in c7213d3Do we still need that?
I don't see it defined or extended anywhere.
Alternatively, can we just use
instantiate_unsupported_reason
and drop theinstantiate_supported?
?ANSWER: punting for now
part of:
Deprecating
unsupported_reason_add
. Returning the string insteadNote, these are all the same: