-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
alias_method
should be preferred to alias
#821
Comments
If memory serves - it was like this in the beginning, but then someone complained that |
Seems this is why things got changed #377 Probably the guide can be updated and everything on |
I'm also for But after reading the discussions (on #377 and others) I feel like In this case, perhaps Rubocop should simply drop any sort of default for this one and have a neutral recomendation in its docs. Leaving the decision for the devs using it. |
Magnificent explanation! As a practical experiment I've replaced all |
TLDNR: The styleguide and
RuboCop
should always prefer the use ofalias_method
.Obscure difference
Ask 100 Rubyists to provide an example where
alias
andalias_method
act differently. I would be surprised if a single one was able to.I admit I couldn't. My friend and co-author of DeepCover couldn't.
The example given in the style guide isn't a good one either (use
alias
and it works in the same way).I had to look it up
alias
sometimes wrong, sometimes not possible,alias_method
always worksThe style guide admits that
alias
can be confusing in some cases and thus says to use it in other contexts.It is implicitly admitted that there is never a case where
alias
actually does something better thanalias_method
does.alias
also doesn't accept a receiver, or variable argumentsinvalid reasons
The reason given in the guide is:
Please ask 100 rubyists what is a "lexical class scope".
It is not the resolution of
self
, but the resolution of the "currently opened class". Theself
is never lexical. Take the example of the blog, wrap thealias
in ainstance_eval
and things remain the same. Wrap it instead in aclass_eval
and things work; both change theself
(here doing nothing as the receiver isself
) but they affect the "currently opened class" differently. I find it quite obscure.How is that an advantage? In these cases, the
self
and the currently opened class are always the same anyways. The existence ofattr_reader
, etc., make it such that we are used to think about the currentself
way more than the current open class.IIC, the idea behind the rule is that only uses of
alias_method
can affect a subclass (say within adef self.inherit
?) and thatalias
won't since its usage is restricted to the simple cases. If so... why is that of any importance? When is that really a concern? When is it not obvious that analias_method
is impacting another class than the current class?Complicated "when to apply"
Asking Rubyists to sometimes use
alias
and sometimes usealias_method
overcomplicates things for no gain.It makes some refactorings awkward:
Note: I'm not sure at all what a "lexical class scope" means, I'm assuming that
RuboCop
's cop is correct here.In short, I feel that
alias
was a language design mistake, an unnecessary keyword that is best avoided.Any rule that attempts to distinguish when to use one or the other adds a complex cognitive load and will make distinctions when there aren't (as in example above). Note that a rule that would say "use alias unless alias_method acts differently" would not make unnecessary distinctions (by definition) but then falls under the "so complex that nobody knows when to apply it".
The one rule
The rule "always prefer
alias_method
" is straightforward, always applicable and can not be simpler. It should be the official rule of this guide and the default of RuboCop.I will gladly provide a PR to fix this guide and RuboCop if it is accepted.
Notes:
alias_method
alias_method
alias_method
alias_method
See also this issue where @Ajedi32 puts forth similar arguments.
The text was updated successfully, but these errors were encountered: