MathTrig - Change Names of funcWhatever to evaluate #2006
Conversation
Per discussions while MathTrig was being broken up, this would help standardize the code. That idea was adopted partway through the breakup. This PR applies that standardization to the earlier efforts. A similar effort is required for DateTime; that will come later. The only 2 remaining funcWhatevers in MathTrig are both in SUM, which required two different methods depending on whether or not string parameters were to be ignored. It seems appropriate to leave those method names non-standardized in order to require a decision about which is to be used if they are invoked internally. I also changed the MatrixFunctions method names as part of this PR. This could create a conflict with PR #2005, even though I think the names I chose in this PR and the names in that one are identical. I can remove that part of this change if desired. 3 Phpstan grandfathered errors were eliminated as part of this change, and its baseline has changed accordingly.
|
Watch out for case-sensitivity in class/method names... we always try to use lower-camel-case for method names |
|
There are too many conflicts with #2005. I am converting to draft while I figure out the best way to handle this. I usually handle conflicts by hand, but that seems too unwieldy here. I could use a suggestion on what you feel the best approach would be. I was not sure what your camel-case comment referred to. I thought all my name changes used 'evaluate'. Possibly you were referring to the 3 matrix functions, which I changed to all lower case as part of this PR. At any rate, please let me know if there are other names that still need attention. |
|
Aha - found uppercase Multiply, Inverse, Identity in my test members. I will resolve those now. |
Upper vs lowercase names.
Let's see if another push clears it.
|
I seem to have done something wrong - Github is "waiting for status to be reported". I will start over. |
|
PHPStorm's merge tool is generally pretty good; but if it doesn't help you, I can probably do them a lot more quickly because I know exactly what I'm looking at |
|
Thank you for the tip. I'll look into it so that I'm better prepared next time this happens. |
|
Closing, replaced by #2008. |
* MathTrig - Change Names of funcWhatever to evaluate Per discussions while MathTrig was being broken up, this would help standardize the code. That idea was adopted partway through the breakup. This PR applies that standardization to the earlier efforts. A similar effort is required for DateTime; that will come later. This PR replaces #2006. The only 2 remaining funcWhatevers in MathTrig are both in SUM, which required two different methods depending on whether or not string parameters were to be ignored. It seems appropriate to leave those method names non-standardized in order to require a decision about which is to be used if they are invoked internally. 3 Phpstan grandfathered errors were eliminated as part of this change, and its baseline has changed accordingly. Co-authored-by: Mark Baker <[email protected]>
Per discussions while MathTrig was being broken up, this would help standardize the code. That idea was adopted partway through the breakup. This PR applies that standardization to the earlier efforts. A similar effort is required for DateTime; that will come later.
The only 2 remaining funcWhatevers in MathTrig are both in SUM, which required two different methods depending on whether or not string parameters were to be ignored. It seems appropriate to leave those method names non-standardized in order to require a decision about which is to be used if they are invoked internally.
I also changed the MatrixFunctions method names as part of this PR. This could create a conflict with PR #2005, even though I think the names I chose in this PR and the names in that one are identical. I can remove that part of this change if desired.
3 Phpstan grandfathered errors were eliminated as part of this change, and its baseline has changed accordingly.
This is:
Checklist:
Why this change is needed?