Skip to content
This repository has been archived by the owner on Jun 2, 2021. It is now read-only.

default option fix #20

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

loadkpi
Copy link

@loadkpi loadkpi commented Apr 16, 2018

fix #19

Copy link

@JelF JelF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Save back-compatibility. It is important.

Imagine following scenarios

  1. Somebody used writer: false to disable auto-assignment of attribute which should be added in attributes (I.e. he overrided reader)
  2. Somebody used reader: false to prevent attribute from exposing into attributes

@@ -26,8 +26,8 @@ def attribute(name, type = nil, **args)
define_writer = args.fetch(:writer, true)

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)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incorrect semantic.

  1. Save define_reader (at least for back-compatibility)
  2. Define private_reader or something
  3. i think, attribute :name, reader: :private serves this case best

@@ -16,7 +16,7 @@ def initialize(*args)

def attributes
self.class.tainbox_attributes.map do |attribute|
[attribute, send(attribute)] if respond_to?(attribute, true)
[attribute, send(attribute)] if respond_to?(attribute)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Private reader should not be exposed. Also you are breaking back-comp here

Copy link

@frvade frvade Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@loadkpi loadkpi Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, you are correct here

Copy link

@JelF JelF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

forgot to request changes

@frvade
Copy link

frvade commented Apr 16, 2018

  1. writer: false removes any opportunity to actually write anything to the attribute. So with this option enabled you must override reader to simulate attribute. Private writer combined with excluding private writers from mass-assignment will solve the problem without having to simulate the attribute behaviour. In any casedefault: setting should work with writer: false.
  2. reader: false disables any way to read the attribute. Why anyone would use it? What if I want to read it inside the instance? To make mass-assignment work with a pseudo-attribute which will set other attributes we can just make the reader private. We will have a reader inside an instance and with the proposed changes it will not show up in the attributes.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect 'default' option behavior for getter
3 participants