Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer methods over instance variables #1166

Merged
merged 1 commit into from
Sep 17, 2015

Conversation

bf4
Copy link
Member

@bf4 bf4 commented Sep 17, 2015

Just a refactor.

Also, extracted latent Adapter::CachedSerializer class. See comments

Basically, wherever options was a method argument in a class, I renamed the @options ivar to instance_options and added an attr_reader. I think it's a good practice to prefer getters/setters over ivars as it gives better failures and encapsulation.

Done in response to #1165 which describes a failure where the options attribute is confused with options.

While changing the options ivars, I just changed all of them.

@@ -91,7 +91,7 @@ def self.serializer_for(resource, options = {})
elsif resource.respond_to?(:to_ary)
config.array_serializer
else
options.fetch(:serializer, get_serializer_for(resource.class))
options.fetch(:serializer) { get_serializer_for(resource.class) }
Copy link
Member Author

Choose a reason for hiding this comment

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

not required for PR, just lazy evals the method when the fetch fails

@scope = options[:scope]

scope_name = options[:scope_name]
self.object = object
Copy link
Contributor

Choose a reason for hiding this comment

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

why prefer self over just the attribute?
it does differentiate from potential local variables. but I'm curious if there is anything else

Copy link
Member Author

Choose a reason for hiding this comment

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

why prefer self over just the attribute?

Not sure what you mean by that.

see my answer #1166 (comment)

@NullVoxPopuli
Copy link
Contributor

I'm mostly just confused on when self should be used.
Seems arbitrary to me in a lot of this pr

@bf4
Copy link
Member Author

bf4 commented Sep 17, 2015

@NullVoxPopuli here's the rules for self in Ruby:

  • Is there a method to get the attribute? Don't use self. Ruby will look for the method unless you've defined a local above it (don't do that)
  • Are you setting an attribute? Use self to ensure you're setting the attribute, and not creating a local variable

@bf4 bf4 force-pushed the clarify_options_variable branch from e918fdc to 28ac9cb Compare September 17, 2015 15:21
@_attributes.concat attrs
@_attributes.uniq!
self._attributes.concat(attrs)
self._attributes.uniq!
Copy link
Member Author

Choose a reason for hiding this comment

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

So, @beauby you're right that these don't need self

@bf4 bf4 force-pushed the clarify_options_variable branch from 28ac9cb to 9d65f0a Compare September 17, 2015 15:45
@NullVoxPopuli
Copy link
Contributor

👍

NullVoxPopuli added a commit that referenced this pull request Sep 17, 2015
Prefer methods over instance variables
@NullVoxPopuli NullVoxPopuli merged commit 61c54bd into master Sep 17, 2015
@bf4 bf4 deleted the clarify_options_variable branch September 17, 2015 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants