Conversation
JelF
left a comment
There was a problem hiding this comment.
Save back-compatibility. It is important.
Imagine following scenarios
- Somebody used
writer: falseto disable auto-assignment of attribute which should be added inattributes(I.e. he overrided reader) - Somebody used
reader: falseto prevent attribute from exposing intoattributes
| definer = Tainbox::AttributeDefiner.new(self, name, type, args) | ||
| definer.define_getter if define_reader | ||
| definer.define_setter if define_writer | ||
| definer.define_getter(define_reader) |
There was a problem hiding this comment.
Incorrect semantic.
- Save
define_reader(at least for back-compatibility) - Define
private_readeror something - i think,
attribute :name, reader: :privateserves this case best
| def attributes | ||
| self.class.tainbox_attributes.map do |attribute| | ||
| [attribute, send(attribute)] if respond_to?(attribute, true) | ||
| [attribute, send(attribute)] if respond_to?(attribute) |
There was a problem hiding this comment.
Private reader should not be exposed. Also you are breaking back-comp here
There was a problem hiding this comment.
Private reader should not be exposed
He is actually fixing this. Now only public readers will show up in attributes. But this will actually break backward-compatibility and needs to be discussed.
There was a problem hiding this comment.
Probably it's better to compare #attributes behavior.
This code has similar results on master branch and on the pull request branch:
Class.new do
include Tainbox
attribute :a1
attribute :a2, reader: false
attribute :a3, writer: false
end.new.attributes
# => {:a1=>nil, :a3=>nil}
For me it's not really clear why respond_to? was used with the option to include private methods in its result before.
So let me know if I miss something.
|
fix #19