Model methods such as live? can cause name conflicts
#703
Milestone
Comments
blakewest
changed the title
It does, and is clearly documented in the API Summary on the README, for models that declare
I'm sorry to hear that. Naming is hard, you are the first person to inquire about this particular method but many of the method names have been updated in the past due to complaints such as this. I don't think it's that common of a name since it hasn't seemed to cause name conflicts prior, but we could consider prepending |
|
Thanks for the reply. Yeah I see that it's clearly documented. Just one of those things you don't really think about as a collision. I agree prepending Thanks for adding it to the V5 roadmap. |
|
There are other potential name conflicts, too. If I'm counting correctly, installing the |
jaredbeck
changed the title
live? can cause name conflicts
jaredbeck
added a commit
that referenced
this issue
Feb 23, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
I have an idea that could reduce this number from 46 to perhaps 2 or 3, and might not be all that complicated: #719 |
jaredbeck
added a commit
that referenced
this issue
Mar 5, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Apr 10, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Apr 10, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 19, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 20, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 20, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 21, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 21, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 24, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
May 26, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 3, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 3, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 3, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 3, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 3, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 3, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 5, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
jaredbeck
added a commit
that referenced
this issue
Jun 6, 2016
Problem ------- `has_paper_trail` adds too many methods to the ActiveRecord model. > If I'm counting correctly, installing the paper_trail gem adds 36 instance > methods and 10 class methods to all of your active record models. Of those > 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the > best way to deal with this is. Ideally, we'd add far fewer methods to > people's models. If we were able to add fewer methods to models, then I > wouldn't mind prefixing all of them. > #703 Solution -------- Add only two methods to the AR model. 1. An instance method `#paper_trail` 2. A class method `.paper_trail` The instance method would return a `RecordTrail` and the class method would return a `ClassTrail`. Those names are totally up for debate. Advantages ---------- - Plain ruby, easy to understand - Adding new methods to e.g. the `RecordTrail` does not add any methods to the AR model. - Methods privacy is more strongly enforced. - Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a mock AR instance. Disadvantages ------------- - Two new classes, though they are simple.
|
Closed by #719, which is expected to be released as 5.2.0. This means that methods like |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It appears Papertrail defines a method "live?" on every instance of every model(/~https://github.com/airblade/paper_trail/blob/master/lib/paper_trail/has_paper_trail.rb#L184). This seems a bit over-the-line to me.
It caused a really unexpected bug on our end, where we had a flag called "live" on our model (which I presume is not a terribly uncommon flag name). We then expected to be able to use the "free" rails method of "live?", which automatically returns a boolean for that attribute (and is general ruby convention for booleans). Instead, it always returned true, which was very very confusing until we realized it was getting defined by Papertrail. And granted, it's already a boolean, and we don't have to use the "?" version, but that's standard ruby convention, and the current behavior seems unacceptable.
We ended up just doing
undef :live?right afterhas_paper_trailin our model, and now it's ok, but that's crazy.Now I realize you can't just go breaking your API, and removing or renaming
live?, but perhaps you could add an option to rename this method to like...paper_trail_live?orlive_version?or most anything else that's more specific, and less likely to crash. I'd also be cool with an option to just not define it at all. We never use it.The text was updated successfully, but these errors were encountered: