|
Now that sounds cool! >-----Original Message----- >From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com] >Sent: Monday, December 06, 1999 1:54 PM >To: RPG400-L@midrange.com >Subject: RE: Runtime KLIST change? > > > > >Alan wrote: >>>> Why, oh why, is RPG adopting pointers, the single greatest >weak point >of >>>>C++ >> >>Because there are certain classes of problems that cannot be solved >without >>them. >> >>A language like Java can get by without them because it is >object oriented >>and, by building new classes, you can extend the language but >somewhere >down >>in those classes somebody has to write in "C" or some other >language with >>pointers. The java class just hides it. > >I'd just like to add a couple of points. Any modern language >that claims to not have pointers is simply playing games with >semantics. Java doesn't have "pointers", but when you're >dealing with objects, you're really dealing with "references" >to objects. Likewise in Perl, you don't have "pointers", you >have "references". Same wine, new bottle, sort of. > >> >>These are options that RPG ILE does not have so you have to >have pointers. >I >>find to write many types of service programs, you just cannot get past >them. >>Any type of dynamic memory allocation (linked list, etc). >> >>Your message does point to the same fear I have. Pointers usage, in my >mind >>anyway, should always be encapsulated in a function and hidden. Using >>pointers in the general body of a program is scary to me and, >of course, >>there is always that fear that someone will misuse a powerful tool. > >Excellent point. Pointers are a very low level concept in any >language. (Pointers are the "goto" of data structures!) >Pointers are best used within a higher-level abstraction. When >implementing some higher-level data structure, such as a linked >list or tree, the user of such a data structure shouldn't have >to know anything about how pointers work. > >Here's an example: You could have a service program that >implements a linked list. One procedure would "create" the >linked list and return a "reference" (really a pointer) to the >data structure. That reference would be passed by the user to >all other procedures within that service program. The other >procedures would handle searching, insertion, iteration, and >deletion operations on one particular linked list. In fact, >this is almost, sort of like object-oriented programming! > >In practice, though, even if you take this style of object- >based design, the users of such a high-level data structure >really can't get away completely from understanding how >pointers work. In this case for example, for the linked list >service program to be completely general, you'd have to deal >with references to the data in each node of the list. This >would be fine if the data in each node were also some form of >high-level "object", but for standard RPG data types, you'd >need at least to define some based variables in your program. > >(Actually, lately, I've been toying with the idea of how to >implement some form of real object-oriented programming in >RPG without having to add any language enhancements by >extending the approach described above. Almost everything >could be handled relatively easily except for the >deallocation of object storage.) > >Cheers! Hans > >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 >+--- > +--- | 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.