|
Hans said: >So, what's wrong with the idea? First, let's have a look at how a >couple of other open-source languages work. Both Perl and Python are >managed by a central core group of developers who maintain and >enhance the code. They also review and approve changes submitted by >others in the general community. That is one way of doing it. Another way is the IBM Apache way, where IBM takes the open source apache, adds some proprietary code, and ships the closed source, binary only "apache for iSeries". My proposal is similar. Release the source code, require websphere to run any offshoot (IBM does not lose $$), get out of the way and let the market decide. >Although I'm sure some RPG fans would love to work with the RPG >compiler source themselves, the community as a whole would not be >served well by multiple RPG compiler products available, each >compiling a slightly different version of the language. Most RPG >shops would still choose to stick with one "official" language. So, IBM requires that the title and marketing of the RPG offshoot language make clear that the new language is not RPG. Does this problem occur with any other languages where multiple vendors are involved? When a vendor produces an offshoot, they just call it something else, and the marketplace decides if the offshoot stays or not. >And so, with an open source RPG compiler, we'd have a community of >developers providing patches to the compiler and a central core >group of developers reviewing, merging code, and testing the >resulting code to produce an approved RPG release. The lab would >need to hire additional people to manage that whole process! yuck! >So what's my point? First, although some people would love to >implement their own changes, the community as a whole would not >welcome a forked language. Second, the time it would take to >understand the compiler code would be a major barrier for most. >Thirdly, a knowledge of the compiler internals is not even necessary >to produce "enhancements" in the form of service programs. RPG can be enhanced with the following: Destructor proc associated with a pointer. When the proc returns, whether normally or because of an unhandled exception, call the proc with the pointer as a parm. This use written proc then deallocs the space, destructs any internal data. MONITOR allows CPF message identifiers. File specs within a proc. Auto open and close the file on proc entry and exit. Namespace support. Specifics are still up in the air. User written BIFFs. Steve Richter
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.