Standardise getters, setters and updaters

[teunbrand]

There are various functions that get or set things, but the names aren't standardised.
Some example getter functions are:

layer_data()
layer_grob()
layer_scales() # these aren't really related to layers?
theme_get()
last_plot()
get_alt_text()

Some example setter functions are:

theme_set()
set_last_plot()

Some example of updater functions are:

update_geom_defaults()
update_stat_defaults()
theme_update()
add_ggplot()/ggplot_add()

The non-standardisation of these functions confuse the API somewhat. For example theme_bw() is a theme in its own right but theme_get() is an interface to the global theme. Likewise, layer_sf() is a specialty layer, whereas layer_data() is not a layer.

I'd like to propose that these type of functions always use a get_, set_ or update_ prefixes so that it is easy to see what getters, setters and updaters are available through tab-completion.

For example we'd have:

get_layer_data()
get_layer_grob()
get_scales()
get_theme()
get_last_plot()
get_alt_text() # identical
set_theme()
set_last_plot() # identical
update_theme()

[davidhodge931]

+1 for this. The consistency proposed here would really help. Don't suppose this could be in 3.5.1?

[davidhodge931]

I also find the prefix update a bit long, which makes update_geom_defaults() hard to read.

Perhaps add_* could be used here instead of update_*?

So:
add_geom_defaults()
add_theme()

Instead of:
update_geom_defaults()
update_theme()

Maybe it's slightly less precise than update, but I feel it's close enough and much more readable

[teunbrand]

The code currently uses 'add' as unofficial indicator that it would work by using + during plot construction in ggplot_add(), add_ggplot() and add_theme(). My preference goes to the get/set syntax for brevity and symmetry reasons.

[davidhodge931]

Oh okay, so have set_geom_defaults instead of update_geom_defaults? I think that'd be way better. I like brevity/symmetry too

[teunbrand]

The expectation for a set_geom_defaults() would be that you have to provide the complete set of default aesthetics, whereas for update_geom_defaults() it is expected you can provide a subset of aesthetics with the rest remaining as-is. That'd be analogous to how the theme_set() vs theme_update() mechanics work.

[davidhodge931]

Assume this isn't planned to be implemented for 3.5.1 @teunbrand ?

[teunbrand]

I wouldn't count on it. It would probably be fine to include in 3.5.1 as it is backward compatible, but priorities for PR review are fixing regressions, safe bugfixes and doc updates. You can take a look at the milestones to see what is planned (and infer what isn't).