[TASK] Deprecate method forwarding OutputFormat to OutputFormatter

[oliverklee]

Instead, the corresponding method on the formatter should be called directly.

This increases type safety and helps static code analysis. Also, it makes the code easier to understand.

[coveralls]

coverage: 55.726%. remained the same
when pulling 255698a on task/deprecate-forwarding
into 44f1b25 on main.

[JakeQZ]

I think we need to provide chaining methods before we can do this.

If you edit __call() to throw an exception in all cases, there are many test failures.

The chaining methods required are clearly-defined by OutputFormatter. There aren't that many.

I think this would be easier and more preferable than rewriting the tests and changing the API - bear in mind that all users would have to expend similar effort rewriting their code as we would rewriting the tests, if we were to change the API.

[JakeQZ]

The chaining methods required are clearly-defined by OutputFormatter.

When they are all in place, __call() can simply be removed.

[oliverklee]

I've updated the calls in #898.

[oliverklee]

I think this would be easier and more preferable than rewriting the tests and changing the API - bear in mind that all users would have to expend similar effort rewriting their code as we would rewriting the tests, if we were to change the API.

I consider the OutputFormatter to be internal to our library (#896), and hence this change should have no effect on users of our library.

[JakeQZ]

I think this would be easier and more preferable than rewriting the tests and changing the API - bear in mind that all users would have to expend similar effort rewriting their code as we would rewriting the tests, if we were to change the API.

I consider the OutputFormatter to be internal to our library (#896), and hence this change should have no effect on users of our library.

I agree, I think. Which is all the more reason to add these methods to OutputFormat so that users don't need to access the underlying OutputFormatter, whether that be by obtaining the object or using __cal().

[JakeQZ]

I think this would be easier and more preferable than rewriting the tests and changing the API - bear in mind that all users would have to expend similar effort rewriting their code as we would rewriting the tests, if we were to change the API.

I consider the OutputFormatter to be internal to our library (#896), and hence this change should have no effect on users of our library.

I agree, I think. Which is all the more reason to add these methods to OutputFormat so that users don't need to access the underlying OutputFormatter, whether that be by obtaining the object or using __cal().

... unless these methods are all meant for internal use. Will need to check...

[JakeQZ]

I've updated the calls in #898.

I think that makes it clear. These are all (only) used by the internal render methods, as a convenience to avoid the extra getFormatter call, and are not intended to be part of the public API. @sabberworm, is that correct?

[oliverklee]

Ping @sabberworm - we need your input here in order to proceed.

[oliverklee]

Please let's get this merged. @sabberworm And input from your side?

@JakeQZ If there's no input from @sabberworm, please let's move this forward nonetheless.