Internal settings container #473
Conversation
|
CI failures are just warnings. Trivial stuff that would obviously need to be fixed, but the PR still works for illustration. |
|
Thanks @vincentarelbundock. I'm a bit tied up over the next day or two, but will take a proper look at this as soon as I can. |
|
absolutely no rush at all |
|
Thanks, Vincent, for suggesting this. I like the approach with the simple The reason for including the The |
|
@zeileis two good points. agreed on both counts. Ideally, I'd like to get rid of And yes, a more consistent solution for ribbon alpha should be on my todo list. |
|
Hi folks. I need to take a quick break from |
|
No specific feedback. More looking for something like "yes I line the idea and it's ok to invest with relatively high likelihood of a merge (no guarantee, obv" Or opposite :) |
|
Ha, got it. In that case, yes, I think that this is a good direction to try out, especially given your parallel experiences with marginaleffects (even if we don't go the full S4 route). I'm optimistic that we would end up merging. |
There was a problem hiding this comment.
Thanks for this @vincentarelbundock... I finallly had time to review.
I've let a quite a few comments. Some of them are nits, some are clarifications, and some are a suggestions for potential improvements.
I have two high-level observations:
-
This container approach is cool, but I think we can tighten up on consistency and (hopefully) efficiency. One concern I have is the fact that we're basically lugging this
settingsitem throughout the internal code, but "manually" reassigning certain elements each time, e.g.settings = update_settings(settings, list(x = x)). In that sense, it's really a glorified wrapper aroundmodifyList(which is fine!). But perhaps we could use the fact that the target is always the same---i.e,settings---to tighten up the implementation so that the code becomesupdate_settings(x = x)? I don't know whether we should enable update by reference, but it could simplify the code further. -
Following on from pt. 1, I'm a little uncomfortable with the fact that many of our internal functions now collapse down to taking a single
settingsargument, without explicitly making clear which settings are going to be extracted or adjusted. (I mean, you can obviously look inside the relevant function, but everything is more hidden.) I don't have an obviously better solution, but perhaps we can tweak the implementation so that instead of, say,
data_abline = function(settings, ...) {
list2env(settings[c("datapoints", "lwd", "lty", "col")], environment())
...
we end up with
data_abline = function(params = c("datapoints", "lwd", "lty", "col"), ...) {
list2env(settings[params], environment())
...Or, if you wanted something fancier, you could extract the function args as strings:
data_abline = function(datapoints, lwd, lty, col), ...) {
call = match.call()
param_names = setdiff(names(formals()), "...")
params = sapply(call[param_names], deparse1)
list2env(settings[params], environment())
...|
@grantmcdermott those were some excellent comments! They lead me to re-think the approach, and I pushed a pretty important change. Now, what we are doing is:
This has three main advantages:
Let me know if that's closer to what you were hoping for. Edit: I know tests are failing. I'll look into it soon. Just wanted to explain the changes I just pushed. |
|
tests pass |
| yaxt_orig = yaxt | ||
| yaxt = "n" | ||
| ylim = c(min(datapoints$ymin), max(datapoints$ymax)) | ||
| type_info = list( |
There was a problem hiding this comment.
I'm probably getting ahead of myself here, but am I correct in thinking that this new settings environment logic will allow us to to remove a lot of the stuff that we're currently shoehorning into the type_info escape hatch?
(I think you might have made this observation in your original proposal; so it's partly a reminder to myself.)
There was a problem hiding this comment.
100%. Could be a separate issue. I plan to do a bit more of this kind of work after this PR is merged.
There was a problem hiding this comment.
One crazy idea would be to push this until we reach delayed evaluation: #121
TBC, that is not my actual plan, and I'm not sure it's actually a good idea. But it could conceivably work.
|
This is fantastic @vincentarelbundock. The Do you mind adding a |
|
News item here: c701699 |
This is a more fleshed out example of the centralized internal settings strategy.
Again, no commitment, but I thought it would be useful to look at what it could actually look like. This currently works with just a named list (no S4), but there are 3-4 of the types have not been converted over yet.
@grantmcdermott @zeileis the file of interesting would be this one:
https://github.com/vincentarelbundock/tinyplot/blob/a913e12e45e593110293a663d201bdb247f94179/R/tinyplot.R