Better names for functions ending in _custom()

[teunbrand]

I'm discontent with the name of some function that end in the _custom() suffix.
Famously, naming things is one of the harder things to do in programming.
I'd gladly entertain alternative names for these.

Currently, it concerns the following functions:

• guide_axis_custom()
• guide_colourbar_custom()
• guide_coloursteps_custom()

[davidhodge931]

An idea is to use guidance_* instead of guide_* for all of your guides. E.g. guidance_colourbar()

I presume all of your guides will act in a similar way with args etc. So then I think it's useful to the user for it to be obvious as to whether the guide is from gguidance or ggplot2.

Also, I think "guid" with autocomplete would give all ggplot2 and gguidance guides, and "guida" would give just gguidance guides. That'd be nice!

Don't know your r package well enough to know if this would be internally consistent with how everything else is named though..

Another idea you've prob throught of is to use 2 instead of custom in the name.

Good luck! Naming is hard

[teunbrand]

I like the idea of using a guidance_ prefix, but the 'guide from string' method of declaring guides, e.g. guides(x = "axis", colour = "colourbar"), requires the functions to have the guide_ prefix. Using 2 as a suffix was what I used in earlier iterations of this package and the reason I didn't stick with it was it nondescript-ness.

[davidhodge931]

Ah damn, didn't think of that...

Only other idea is a play on words. But would need to be misspelt unfortunately..
guide_ance_axis()
guide_ance_colourbar()
guide_ance_coloursteps()
guide_ance_colour_ring()

guides(x = "ance_axis", colour = "ance_colourbar")

Not sure whether this is good or not. The strings look a little weird. But it's another idea anyway

[davidhodge931]

Maybe the above is too weird.

If you use a word in your guide names like 'custom', I think you should consider applying it to all of your guides - given that they will all operate with this custom-ness/flexibility - and this would identify them as being from your package.

Other ideas for this word are flexible, flex, flexi, ply, plyr or plie..

[aphalo]

@davidhodge931

Only other idea is a play on words. But would need to be misspelt unfortunately..

What about adding a "d":

guide_dance_axis()
guide_dance_colourbar()
guide_dance_coloursteps()
guide_dance_colour_ring()

guides(x = "dance_axis", colour = "dance_colourbar")

Probably too crazy and too long, but easy to remember.

[teunbrand]

I like the dance infix, but I'm not sure I'd want to mark all functions that way. I also like _flex() as a suffix. I'll let this percolate for a while, thanks for the suggestions!

[davidhodge931]

Another idea is to just accept the namespace collision, and people can type out ggh4x::guide_axis, ggh4x::guide_colourbar and ggh4x::guide_coloursteps etc

If you are using these functions, then you will be aware of ggplot2 versions of these functions, and the collission won't be unexpected

[aphalo]

@davidhodge931 I think 'ggplot2' will be attached first, so the functions defined in extension packages with the same name as in 'ggplot2' will be the visible ones if the package is attached. Without attaching the 'gguidance' package, your approach would work, but I think it would surprise too many users as they most likely attach the package as usual. However, your idea made me think of another approach: this would be to set the default behaviour of the functions in 'gguidance' to match that of the 'ggplot2' equivalents, e.g., by calling the 'ggplot2' functions from within the new functions in the default case. The new behaviour would be triggered by arguments passed in the call by the user. Thus, reusing the same function names would not break any code based on 'ggplot2', and work smoothly as long as not more than one attached package uses this same approach.

[teunbrand]

The issue with overwriting ggplot2's function is that I do not intend to keep backwards compatible with pre 3.5.0 guides, whereas ggplot2 makes some effort in maintaining this. So it isn't a perfect superset of functionality in gguidance, which might confuse folks.

[davidhodge931]

Yeah, namespace collision would cause unnecessary problems.

Of all naming ideas suggested so far, I think guide_axis2, guide_colourbar2 and guide_coloursteps2 is my fave.

It's concise and it explains to the user that it relates to the equivalent ggplot2 function but with some extra gguidance stuff.

It also correlates with the approach {ggh4x} used for facet_wrap2 and facet_grid2

[teunbrand]

I might've just have an epiphany for the colourbars/steps. I can call them guide_colbar() and guide_colsteps(), which is shorter and doesn't pick a side in US/international spelling. Should also make guide_colring() then.

[davidhodge931]

A creative idea, but I think I still prefer just using 2's.

It also would work if you choose to make {gguidance} versions of guide_bins, guide_axis_logticks, guide_legend etc in future too

[teunbrand]

I think I'll just name the axis guide_axis_base() which is shorter than custom and indicates that it mirrors vanilla ggplot2's axis.