Should R7 offer encapsulated OO?

[hadley]

It turns out to be trivial (#191) to add encapsulated methods to R7 (i.e. methods that belong to the class/object):

foo <- new_class("foo",
  properties = list(
    x = "numeric",
    y = "numeric"
  ),
  methods = list(
    bar = function(self) {
      print("Hi!")
    },
    baz = function(self) {
      self@bar()
      self@x + self@y
    },
    change = function(self) {
      self@x <- self@x + 1
      self
    }
  ),
)

x <- foo(x = 1, y = 2)
x@baz()

The current trivial implementation:

• Handles within package inheritance of methods. Cross-package inheritance needs a little more work to ensure that we don't take a dependency at build-time, rather than load-time (so that environments of the methods match the currently installed package). Would need to adjust super() implementation to support method access.

• Doesn't have particularly good performance. Prformance will improve a little with a base C implementation of @, but would require byte code compiler transformation for high speed.

Currently mutability "just works" if you inherit from environment:

foo2 <- new_class("foo", "environment",
  properties = list(
    x = "numeric"
  ),
  methods = list(
    up = function(self) {
      self@x <- self@x + 1
      invisible(self)
    }
  )
)

x <- foo2()
x@x <- 1
x@up()
x@x

But a full implementation would need careful consideration of how validate() should work to ensure that objects aren't left in an invalid state.

Overall, I'm pretty neutral on this proposal. There are some big upsides, but also some big downsides. Here are a few of the pros/cons that I've considered so far:

• It's often handy to encapsulate code that only operates on objects of a certain type in to the class, rather than leaving as a free floating function (which typically needs some prefix to avoid clashes with other function names).
• From the outside, encapsulated methods behave similarly to dynamic properties, which we already allow.
• Encapsulated OO allows R7 to also offer an equivalent to R6 (although the performance won't be as good). For better or worse, folks coming from other languages usually find this style of OO more familiar.
• Most modern language use special syntax for in-place mutation. In the code above there's no way to know that x@up() is actually modifying x in place: this is potentially extremely confusing.
• Would need to think about encapsulation of methods. Maybe a convention that internal methods start with . would be sufficient? Since they wouldn't be documented and wouldn't be suggested by auto-complete, it would be unlikely for uses to accidentally use them.
• It's confusing to provide two different styles of OO in one system. How would developers know which to use when?

[mikmart]

The discussion in #245 made me wonder if static methods/associated functions would be useful. That would allow "alternative constructors" etc. to live inside the class. No idea if this is feasible, but I was thinking like:

range <- new_class("range",
  properties = list(
    start = class_numeric,
    end = class_numeric
  )
)

range@from <- new_generic("range@from", "x")

method(range@from, class_numeric) <- function(x) {
  range(min(x), max(x))
}

range@from(1:5) == range(1L, 5L)

I notice something like this has been considered based on the note about "class methods that lack self" in #191.

[lawremi]

The above idea is interesting and probably deserves its own issue. Since classes are objects, we would probably want some other syntax than @ for accessing static members. Maybe just $.

[tkinsf]

So, what happened to this idea? I'm coming from other languages and this "functional oop" seems bizarre to me. I was looking into converting my 7 yo R code because I couldn't make heads and tails out of it. Frankly, I don't know if I'll be gaining much by rewriting if the methods and the class are separate and all over the place. The whole point of OOP, at least to me, is intuitiveness, readability and maintainability. None of that seems to apply to S7. You already have constructor; why not have methods defined in the class as well, instead of requiring the user go through the hoops of generic() and the method(), etc, and then invoke it like a stand-alone function? x.up() is much more readable than up(x), and I'll have easier time maintaining up() if it is encapsulated within x's class.

[hadley]

@tkinsf this is not the place to argue about functional vs encapsulated OO, but I'd strongly encourage you to learn more about functional OOP because IMO it's a great match for the types of problems you tend to solve in data science. One place to start might be https://adv-r.hadley.nz/oo-tradeoffs.html.

[tkinsf]

I take that this idea was shelved then? Thank you, I'll move on.

…

On Thu, Jan 11, 2024 at 5:27 AM Hadley Wickham ***@***.***> wrote: @tkinsf <https://github.com/tkinsf> this is not the place to argue about functional vs encapsulated OO, but I'd strongly encourage you to learn more about functional OOP because IMO it's a great match for the types of problems you tend to solve in data science. One place to start might be https://adv-r.hadley.nz/oo-tradeoffs.html. — Reply to this email directly, view it on GitHub <#202 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADU7KY6MCKFEKEBPE3B2KTDYN7SFZAVCNFSM5QEZGVA2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYG4YTMMZYGAZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>