|
Hi Joe! >> Unless you write your own procedure/function to do these >> sorts of common date manipulations. What goes on inside >> the function (MOVE) is irrelevant to the fact that you >> can use your own function Exactly The Same Way you >> would use an IBM BIF. > >The problem with this statement is that now I have to >write a BIF to do what already works in previous code. I'm feeling goofy today so I'll kick in one more comment. In my opinion, using MOVE to fiddle with dates has never been a good idea. At least not a bare MOVE. Let's say that I have some program that has several dates on the panel: order date, ship date, received date. For whatever reason, the panels still use decimals and not date fields, so we need to convert back and forth. The simple way would be to do three MOVEs and be done with it. But then your company is acquired by a European firm, and they like to see their dates in a different format. Those MOVEs need to be tracked down (all of them) and wrapped in some IF/ELSE or SELECT statements. Then, testing reveals some odd proclivity on the part of North American users to type the dates in "wrong" so we need to add error checking. Track those MOVES down again and add some error handling. Sounds Very Much like a job for a subroutine call in RPG III. Which is exactly what it ALWAYS should have been. Now, all the date conversion happens in a single bit of code, preferably /COPYed in. Which is exactly what we used to do for similar "utility" functions back on System/3 RPG II. >This is added work on my part, with zero return on >my investment. I have to not only write the BIF, >but also debug it to make sure it handles all the >situations that same way that the original code did. Au contraire, mon ami! For, if I skipped the debugging/error handling/multiple format allowing parts before (naked MOVE), I am now in the land of "pay me now, or pay me later." The reward on that investment is more robust code, and more easily maintained code, since it's all in one place now instead of scattered piecemeal throughout the various and sundry programs that make up the application. >It is not reasonable to do that just to use a new >version of the compiler. New Development (we ARE talking about new code, right?) really should be re-written, not merely translated from an older dialect to a newer one. THAT provides zero return on my investment. If I am going to use /free, why not make the code better (more robust, easier to maintain) instead of merely re-hashing its appearance? >Let's take an example. I write code for an ERP manufacturer. >In the next release of our package, I go to my boss and say, >"it's going to be too difficult to support order policy X" >or "order policy X doesn't fit in with where I see the >package going". What Toronto have done is closer to releasing NEW and DIFFERENT function at the expense of moving older working function into the new framework. More like trying to wedge version 1 BOM functions into the version 2 interface. >This is EXACTLY what has happened with the MOVE >opcode in freeform RPG. Here's my take on that, and it's worth every penny you paid for it. 1) The entire argument is Very Reminiscent of the perennial favourite "The Cycle Rules/Sucks" debate. Some people care for the cycle, some don't. My guess is that some people will simply never really care for /free. Not a problem. Don't use it, and feel better about life. 2) /free is closer to a new language than it is to RPG II. I really prefer to drop the RPG II baggage behind altogether, but the political realities are not going to let that happen. As it is, _this_ debate has probably stunted further development. 3) Should Toronto feel motivated to implement MOVE as a free form operation/BIF (and they very well might be!) I humbly suggest naming it with a realistic name (and I am not kidding): MoveAndConvertDataTypeAndFormat hits most of the high points. 4) We didn't LOSE anything; we GAINED new functions. Not all of the new functions map directly to old functions. Providing new function while allowing use of existing function is a very reasonable way to allow me to embrace new ideas at my own pace. 5) Relying on the compiler to solve business problems is a dangerous precedent. The compiler should provide me with tools to write my own solution to my own problems. There is a reasonable argument that date conversions are business problems which depend on the nature of the application. Reasonable people (which does not include me, of course) can honestly debate where the line should be drawn. A similar argument exists around the new IFS function and the new XML functions and CGI and... 6) I would argue that the entire date functionality was never fully implemented in the compiler in one fell swoop (and it's still coming out...) Early adopters already wrote their functions to slide between decimal and date. Later adopters are waiting for the compiler and that's OK _for them_. But don't hold us ALL back because some folks don't need that new functionality. If somebody TODAY wants to do these date manipulations and INSIST on /free, then they are more akin to an early adopter, and will need to do more work than those who follow. Best regards to all and I'm outta here. --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.