[PHPUnit 10] Questions regarding the implementation of `assertStringEqualsStringIgnoringLineEndings()`

Copied from https://github.com/sebastianbergmann/phpunit/issues/4641#issuecomment-1003828421 for visibility:

I've just been looking at the implementation of #4641 and it raises some questions with me regarding the assertStringEqualsStringIgnoringLineEndings implementation:

1. The term Equal (as in assertStringEqualsStringIgnoringLineEndings) is generally used for loose type comparisons in PHPUnit, but is used here for a type safe comparison.
2. The actual comparison done is (mostly) type safe (Same) and would be so even when strict_types would be turned off or if the type declarations in the method would be changed to mixed, due to strtr() being used, which always returns a string.

So, my questions are:

• Is assertStringEqualsStringIgnoringLineEndings() the correct name/assertion to be added ? Or should there be an assertEqualsIgnoreLineEndings() and an assertSameIgnoreLineEndings() ? This also implies that the normalizeLineEndings() method should allow for receiving mixed type, do a type check and would only normalize if the received type is actually a string (and return the original value unchanged if it isn't).
• And if the new assertions would be transformed like this, what about also recursively handling string values in arrays to allow for a comparison of arrays ignoring line endings ?

I'd be happy to attempt a PR for this, but would like your opinion about this first.

Oh and another question: should there be Not versions of these assertions available ?

@jrfnl I think @sebastianbergmann is the right one to answer you first question. Regarding the second one I think it is a great idea, I'll start working on it.

assertStringEqualsStringIgnoringLineEndings() does exactly what I think it should do: it compares two strings while ignoring line endings. It only accepts string arguments (string $expected, string $actual) and even has the substring String twice in its name.

Maybe I am missing something here, but I do not see anything wrong here.

No feedback, closing.

I didn't think you were asking for feedback as your previous comment seemed to dismiss my concern out of hand...

(without really answering any of my original three questions)