Revising report due to changes in "parameters" package about report

[DominiqueMakowski]

That's on my roadmap, on the dev branch I have initiated the cleanup. The reorganization might be the occasion to streamline how report works.

In particular, I am thinking about making report() (for most reg models) build upon two functions, model_table() and model_text(). The former would be the combiner of performance, parameters and effectsize into a nicely displayed table, and the latter would take such table and transform it into text. As mentioned by @mattansb somewhere, the first model_table would be a priority indeed. There is a "basis" (the internal generic for reg models) on the dev branch, if you wanna give it a look!

[DominiqueMakowski]

I mean, to date, report has been quite unstable (mostly breaking whenever something was changed upstream) and a hassle to fix because of its clunky implementation. So if we make this right, then it will be easier to catch and fix all bugs. Hence, a workflow of model_table()+ model_text(model_table()) = report() seems appropriate, because the only critical point is to make sure model_table gives the good table. Because model_text would be mostly generic (i.e., disconnected from upstream dependencies, only caring about the info provided to it), as in if it detects an R2, a coefficient and a CI columns it puts into a given text.

[DominiqueMakowski]

Does such a design make sense to you?

[strengejacke]

Does such a design make sense to you?

I think sometime I need to take a closer look and get a more comprehensive picture of how report-functions work together, so I can better judge this... But you know, I believe (in) you. ^^