See 3.3. ::CLASS in <A href="https://www.oorexx.org/docs/rexxref/rexxref.pdf";>ooRexx Documentation 5.0.0 Open Object Rexx Reference</a>.
"When the only tool you have is a pipe, everything looks like a filter". Inheritance, like most tools, is useful in the appropriate context but is not a magic bullet. You can program FORTRAN in any language. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of David Crayford [[email protected]] Sent: Friday, June 2, 2023 8:34 PM To: [email protected] Subject: Re: Are there samples of COBOL methods or classes? On 2/6/2023 3:47 am, Bob Bridges wrote: > I first got the hang of oo programming using VBA, and later VBS; consequently > I don't think much about inheritance. But when I finally broke down and got > myself a copy of ooRexx, I see the manuals have a lot to say about it. > Mostly I read those parts skimpily and have never yet had occasion to use > those features. > > I wonder, though, whether your objections apply as thoroughly to ooRexx as > they do to some other languages? I seem to recall that ooREXX has a way of > specifying which methods a class inherits from other classes. Might not that > obviate some of the problems? When discussing the challenges associated with inheritance, it's worth noting that these issues are not specific to any particular programming language, including ooRexx. It is important to approach this topic with the utmost respect for the language and its community, such as Rene and Rony, who are widely recognized as talented and esteemed individuals in the ooRexx space. Everyone in this forum is well aware of my thoughts and opinions regarding REXX. In the early 1990s, the challenges associated with inheritance had already been recognized within the software development community. At that time, a group of IBMers, known as the Gang of Four (GoF), authored a groundbreaking book titled "Design Patterns." This seminal work tackled the inheritance problem head-on by offering reusable design patterns as solutions. Even today, this book remains an invaluable resource that I personally refer to, considering it a true masterpiece. https://en.wikipedia.org/wiki/Design_Patterns The key point "Prefer composition over inheritance" is a principle in software design that suggests using object composition instead of class inheritance. It promotes flexibility, code reuse, and maintainability. Composition involves combining simpler components to create more complex objects, allowing for greater flexibility and modularity. It reduces coupling between classes and promotes loose dependencies, making it easier to modify or extend functionality without affecting other parts of the codebase. By favoring composition, code reusability improves as smaller components can be reused in different configurations. Encapsulation and interface-driven design are emphasized, leading to modular and interchangeable implementations. Composition helps separate concerns by dividing complex functionality into smaller, specialized components. This improves code readability, testability, and maintainability. While inheritance still has its uses, the principle encourages developers to consider composition as the default approach for achieving flexible and maintainable designs. It's worth noting that some modern languages, such as Rust and Go, do not support inheritance, effectively enforcing this principle. > > --- > Bob Bridges, [email protected], cell 336 382-7313 > > /* Question: Would you rather raise a child who grows up to be (a) an > honest, ethical, family-centered person who works on an assembly line or (b) > a habitually dishonest, amoral narcissist who is the CEO of a big > corporation? If your answer is (a), then answer this: Which child would you > brag about more? -John K Resemond, "Who's in Charge Around Here?"; United > Airlines' magazine "Hemispheres", Sep 1999 */ > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > David Crayford > Sent: Thursday, June 1, 2023 07:25 > > I totally agree that Object-Oriented (OO) programming hasn't lived up to all > the hype it once had. But I have to disagree with the idea that code reuse is > the only purpose of OO. It's actually more nuanced than that. > However, if we're talking about code reuse and Java, just take a look at the > Maven central repository. It's got a whopping 400,000 unique artifacts and > handles a mind-blowing 70 million downloads every year. > Now that's some serious code reuse, and it's all thanks to the open-source > community. Pretty amazing, huh? > > I think a lot of the misunderstanding about OO is related to inheritance > which was popular in the 90's but not so much now now. Inheritance is not > inherently bad in OOP, but it can have drawbacks when misused or overused. > Here are a few reasons why it can be problematic: > > 1. Tight Coupling: Inheritance creates a strong connection between > classes, making changes in the base class impact all its subclasses, > which can make the code fragile and less flexible. > > 2. Inappropriate Subclassing: Using inheritance when it's not suitable > can lead to confusing and convoluted code that is hard to understand. > > 3. Complexity: Large inheritance hierarchies can become complex and > difficult to manage, leading to maintenance issues. > > 4. Code Duplication and Rigidity: Inheritance can result in code > duplication and make it challenging to modify the base class or > rearrange the hierarchy. > > 5. Limited Reusability: Inheritance can restrict code reusability by > tightly binding subclasses to their base class, limiting their use > in different contexts. > > It's crucial to use inheritance judiciously and consider alternative > approaches when appropriate to avoid these potential drawbacks. Modern > languages such as Go and Rust do not support inheritance. They support > interfaces (traits) which are fundamental for polymorphism. > > Polymorphism reduces the need for extensive if-else logic by allowing > different objects to respond to the same method call in different ways. > Instead of using if-else statements to check the type of an object and > perform specific actions, polymorphism enables us to define common methods in > a superclass or interface and rely on the specific implementations in > subclasses. > > No need to define encapsulation (data hiding) as we all know what that is. > The WORKING-STORAGE section in COBOL really highlights the stark differences > between COBOL and modern languages. In COBOL, all data, including loop > indexes used within a routine, are global. Nowadays, this global scope for > data makes me quite uncomfortable, especially when I'm accustomed to being > able to declare variables within specific blocks like for loops or if > statements. Unfortunately, COBOL doesn't excel in terms of lexical scoping, > which is a strong point in modern programming languages. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
