On Sat, Apr 16, 2022 at 12:23:10PM -0400, David Mertz, Ph.D. wrote: > R doesn't have inheritance, it's not OOP,
R is OOP and always has been. All values, arrays, functions etc in R are objects. Even expressions are objects. And it has inheritance. https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Objects https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Inheritance R has three mechanisms for implementing classes, S3, S4 and Reference classes (unofficially known as S5). All three of them allow inheritance. http://adv-r.had.co.nz/S3.html > One thing I do find a bête noire is the silly claim, that Chris repeats, > that inheritance expresses "Is-A" relationships. "Is-a" is fundamental to the relationship between a class and its instances. Inheritance is orthogonal to that relationship, e.g. Swift only allows single inheritance. Every class can only have a single superclass, which defines what kind of thing the subclass is. But it can inherit from multiple mixins or traits, which allow it to inherit behaviour. In Python, virtual subclassing defines that "is-a" relationship without inheriting anything from the parent class. > The reality is more clear in the actual primary definition of the word > itself: "the practice of receiving private property, titles, debts, > entitlements, privileges, rights, and obligations". That definition is incomplete when it comes to inheritance. If I go to the store and purchase a bottle of milk, I have received private property. That's not inheritance. If I receive a knighthood for slaughtering my monarch's enemies, that is also not inheritance. My obligation to pay taxes when begin to earn income is another thing which I receive but is not inheritance. > In programming, a class > can receive methods and attributes from some other classes. That's all. > It's just a convenience of code organization, nothing ontological. That might be how Alan Kay originally saw OOP. He famously regretted using the term "object" because it distracted from what he saw as the genuinely fundamental parts of OOP, namely * Message passing * Encapsulation * Late (dynamic) binding Purists may also wish to distinguish between subclassing and subtyping. Raymond Hettinger has given talks about opening your mind to different models for subclassing, e.g. what he calls the "conceptual view" vs "operational view" of subclassing. Or perhaps what we might call "parent driven" versus "child driven". https://www.youtube.com/watch?v=miGolgp9xq8 But whether we like it or not, the concepts of subclassing and subtyping are entwined. We model "is-a" concepts using classes; we implement code reuse using classes; we model taxonomic hierarchies using classes. Classes are flexible; they contain multitudes. -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/G6KLP7QVS3RXWJYNIEPX22DHJFUA6HZO/ Code of Conduct: http://python.org/psf/codeofconduct/
