> > Raku's OOP was designed to support proto-type programming > > and method delegation straight out-of-the-box. > > Can you give us a pointer to some code examples on how to use > Raku for prototype-style OOP? I can think of ways to do it, but I > don't know that I see any advantage in it.
Depending on how you look at things, Raku is already replete with prototype-based OOP, and you're probably already using it all over your code without realizing it. Do you mean advantage of prototype-base OOP over class-based in general, or advantage of prototype-based OOP in Raku over class-based OOP in Raku? In S12 Larry wrote: > We wish to support both class-based and prototype-based OO programming. There are millions of devs who are familiar with using prototype-based OOP and it behooves us to let devs know that Raku has their back. > Class-oriented OOP is a pretty common way of doing it Oh, absolutely. A ton of the OOP built into Raku uses it. Many devs are used to using *only* class-based OOP. And we want them to know we have *their* back *as well as* those who do *not* want to be stuck with the problems that arise with overuse of classes. > you're just making the point that there are other ways. No. I'm not just making that point. Yes, there are other ways, but that's not my point. Perhaps you stopped reading part way through my prior email? I will try to more clearly convey my point by quoting what I wrote in the part you may have just skimmed, and add a bit more to try to bring out its import. > Undue reliance on inheritance (the primary mechanism used by classes to organize methods) was recognized in the 1980s to be a major problem when overused. Larry understood this. I think it's important that Rakoons know it too, doubly so if they widely share a summary about OOP as a Rakoon and/or OOP in Raku. I'm not saying Todd *is* going to share his keeper widely, but it looked substantive, and like a work of love and care, so it seemed like he might be intending to share it beyond this thread. > Raku's OOP was designed to enable developers to avoid over use of classes / inheritance. To do that, you have to use constructs other than `class` as the data structures from which objects are built and as the organizing framework via which methods are selected. If you *don't* use those alternatives you will end up overusing classes/inheritance for anything beyond simple use cases. > In conclusion, I think it behooves Rakoons to be aware of: This was my key point: awareness. Once folk are aware, they can observe, learn, understand, and adapt. > Composition over inheritance A google for "composition over inheritance" hints at its import: https://www.google.com/search?q=%22composition+over+inheritance%22 The Wikipedia page shown by the above google search is a reasonable introduction. (Reasonable in general, but the Raku line only mentions delegation via `handles` when in fact the much more important relevant Raku feature is `role`.) > Prototype oriented programming and delegation I note that you skipped delegation. In case you weren't sure what that is, it's the `handles` trait on a variable, or a mixin of a `role`. > Problems with (overuse of) inheritance / classes That problem mostly goes away in Raku if there's simply awareness and understanding of the problem and of the simple Raku tools for solving it. > How Raku's OOP nicely addresses all of the above For example, use of `role`, `but`, `does`, `handles`, and `.clone`. -- love, raiph
