|
Jim wrote: >Overloading is purely an OOPS thing, and you could do the same thing with >*OMIT or *OPTION in RPG, although not exactly the same. then Aaron wrote: >Agreed. I have this new thirst since I have started coding in Java. Java >definitely has some cool features that I think are within the reach of RPG. >Will the RPG group ever look at overloading? Hans? You really want my opinion? Well, you asked for it! (If you want a quick answer, skip down to the "bottom line" below.) First off, overloading has nothing to do with OO. Some OO languages (like Java and C++) have special rules for overloading, other OO languages (like Perl, Python, Object Rexx, Smalltalk - ie. the "good" OO languages) don't. Furthermore, there's no reason you can't have overloading in non-OO languages. C++ can (and often is) programmed in a procedural manner, and overloading can still be taken advantage of. Is overloading a good thing? Well, that point is certainly debatable. To answer that question, let's look at how my favorite language, Python, and the other interpreted OO languages, handle overloading. In those languages, basically, everything is an object. Since everything is an object, and method parameters are basically of one type, object, the concept of overloading is both implicit in the language and of no consequence whatsoever. What you can do with particular objects is determined solely at run-time. The way compiled languages do overloading, on the other hand, is typically a consequence of the compilation process, because it makes the difficult task of compilation easier. Compiled languages tend to be strongly typed, not just to help ensure program correctness, but also to be able to generate efficient code. (The former is often more of a convenient excuse for the latter, rather than a noble goal, in my humble opinion.) In compiled languages, overloading is achieved through special syntax and semantic rules because of the strong typing in those languages. Strong typing, to a great extent, really goes against the grain of OO philosophy. And so, special rules for syntax and semantics have to be grafted on top of the languages in order for these languages to behave sort of like the real (interpreted) OO languages. A direct result of these rules is the persistent nuisance of always having to cast the types of object pointers in compiled OO languages. (BTW, regarding Java, I've always said that Java is a language that combines the disadvantages of compiled languages with the disadvantages of interpreted languages.) Did that make any sense? No? Well, who cares! What about RPG? RPG may never become fully OO, but then that's a different question than overloading, isn't it? Overloading of procedure parameters may well come about when (or rather if) the different IBM sites involved (at least three at last count) can get their acts together and enhance the operational descriptor support in the system. In that scenario, RPG would have a "don't care" type for reference (and perhaps const) parameters, and the programmer would be responsible for determining type of parameter and taking the appropriate action depending on the type. BOTTOM LINE: Overloading in the style of Java or C++ I don't see in RPG due to the complexity of implementation compared to the benefits. Cheers! And have a good Wednesday. Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.