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

Add Sorbet/TStructPropertyAttrMacro #182

Closed
wants to merge 2 commits into from
Closed

Conversation

sambostock
Copy link
Contributor

In a T::Struct, attr_* methods shouldn't be used for properties.

 class Foo < T::Struct
-  attr_accessor :bar
-  const :bar, ...
+  prop :bar, ...
 end

context("and the names match") do
it("registers an offense") do
expect_offense(<<~RUBY)
class Foo < T::Struct
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should detect this in other classes as well (T::ImmutableStruct, and probably others too).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've updated the cop to look for T::ImmutableStruct, and T::InexactStruct as well. I'm not sure if it's worth the trouble to look for anything else (e.g. T::Props), as it would require also scanning for included modules, and would probably be more brittle.

it("registers an offense") do
expect_offense(<<~RUBY)
class Foo < T::Struct
attr_writer :bar
Copy link
Contributor Author

Choose a reason for hiding this comment

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

One case in which this might be legit would be if the writer's sig is more restrictive:

class Foo < T::Struct
  sig { param(number: Integer) }
  attr_writer :number
  
  const :number, Numeric
end

Less restrictive would be an error, although would be hard to check for.

This would be pretty unusual though, and arguably a better named method would probably make more sense, so it's probably safe to just assume that if attr_* is being used, it's incorrect usage, and let the author of such an exotic usage simply disable the cop.

@sambostock sambostock self-assigned this Oct 10, 2023
@sambostock sambostock added the feature Add a new feature label Oct 10, 2023

This comment was marked as resolved.

@github-actions github-actions bot added the stale label Nov 9, 2023
@sambostock sambostock removed the stale label Nov 9, 2023

This comment was marked as resolved.

@sambostock sambostock force-pushed the t-struct-attr-macros branch 2 times, most recently from ee78171 to f5ed82e Compare December 29, 2023 06:20
In a `T::Struct`, `attr_*` methods shouldn't be used for properties.
Instead, `prop` should be used instead of `const` to make a mutable
property, and all simple accesses should go through the generated
methods.
The only case where a custom reader or writer should be used is if the
logic is being customized.
@sambostock sambostock marked this pull request as ready for review December 29, 2023 06:23
@sambostock sambostock requested a review from a team as a code owner December 29, 2023 06:23
@sambostock sambostock requested review from andyw8 and Morriar December 29, 2023 06:23
# end
class TStructPropertyAttrMacro < Base
MUTABILITY_MSG = "Use `T::Struct.prop` instead of `%{keyword}` to define `%{name}` property as mutable."
OVERRIDE_MSG = "Do not override `T::Struct` `%{name}` property %{attr_method_type} unless customizing it."
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's remove the unless customizing it as it's not really recommended and could be confusing here.

end

def attr_method_type
keyword.to_s.delete_prefix("attr_")
Copy link
Contributor

Choose a reason for hiding this comment

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

It may make more sense to actually keep the prefix to make it extra obvious that the attr_writer/attr_reader/attr_accessor is the problem

@andyw8 andyw8 removed their request for review January 9, 2024 16:59
Copy link
Contributor

github-actions bot commented Feb 9, 2024

This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Feb 9, 2024
@github-actions github-actions bot closed this Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Add a new feature stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants