Closed (fixed)
Project:
Simplenews
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 Jun 2018 at 19:00 UTC
Updated:
6 Mar 2019 at 15:29 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
subson commentedComment #3
subson commentedAdding patch for review.
Comment #5
tr commentedIn addition to what the testbot is telling about the duplicate MessengerTrait, almost all of the t() should be replaced by $this->t().
Comment #6
subson commentedFixing the duplicate MessengerTrait issue, will create a separate issue for t() replacement with $this->t() as there are lot of references of it in the code.
Comment #7
subson commentedSeparate issue created for $this->t() change - #3002237: Replace usage of t() with $this->t()
Comment #8
subson commentedComment #10
tr commentedI didn't mean you should fix all the t() in the entire module at the same time as you introduced the messenger service, I meant your NEW code should not use t(). Likewise, it shouldn't use array(). All the NEW code should conform to the coding standards 100%, otherwise you've just created more things that need to be fixed "later". We shouldn't have to change the same lines of code three times (once for messenger, once for t(), once for array() ...), and we shouldn't be committing code with known problems when it's trivial to avoid those problems altogether.
Comment #11
adamps commented@TR You make some excellent general points. However in this specific case, I would like to put forward an alternative point of view. This patch is itself a tidy up issue. The patch does not really write NEW code, it simply does a bunch of search and replace.
I think that if we block fixing one type of tidy up because another type of tidy up is required then it becomes hard to ever tidy up. I don't think it's entirely trivial to fix all the t() and array() as well. I think the patch becomes harder to review if it includes all of those too.
The patch has not "just created more things that need to be fixed later", but in fact exactly the opposite, less of them. There are the same number of problems with t() and array() as before but all the deprecation warnings have gone. Clearly the code is in a better state than before - it removes a lot of irritating junk from the output of running tests.
I vote for commit.
Comment #12
adamps commentedI plan to commit this in one week unless there is some new objection.
Comment #13
tr commentedThe status was at "Needs work" solely because the tests failed - I did not set the status, and I was not blocking the issue. As the maintainer, it's up to you how you want to manage the project.
Comment #14
adamps commentedThanks @TR. I have only just become a maintainer this week, so whilst I am learning my way I am keen to check I don't create problems for others.
Comment #15
adamps commentedComment #17
adamps commented