Adopting S7 OOP

[teunbrand]

This issue is to put to writing an idea that Thomas and I have discussed off-GitHub.

There are some issues with the S3 OOP system that cannot be resolved in a satisfying way, notably #3986, #5536 and some additional plans that'd require double dispatch. The solution I'd like to propose is to use S7 OOP instead. This has been attempted before in #5537, which we put on hold until S7 was more mature. I think that might be the case.

We can expect some reverse dependency failures when we adopt S7 and it may make sense to bump the major version due to this. Possibly, we can mitigate a series of failures by implementing $-methods that are list-like.

[teunbrand]

Listing what systems/classes might adopt S7:

• The ggplot class
• The theme class
• The element classes
• The uneval class (from aes())
• The labels class (from labs())

Please feel free to comment more that I might've forgotten.

[teunbrand]

So I'm running into a crinkle with regards to naming conventions. Essentially, the guidance from S7 is that classes should have the same name as the object that stores the class e.g.:

foo <- S7::new_class("foo")

However we have several instances where we'd clash between a generic constructor (think ggplot() that has a 'default' and 'function' method) and a class object. My proposal is that we use a class_-prefix to clearly denote when using the S7 class. As an example, we'd use class_ggplot <- S7::new_class("ggplot", ...) and let ggplot() remain a function that constructs on object using class_ggplot().