|
> From: Buck Calabro > > 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. 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. It is not reasonable to do that just to use a new version of the compiler. What's next? Remove the %trim function and let me write my own? The correct answer is that every opcode removed should be, at the minimum, supported by a BIF in the next release. If it's difficult, well, guess what? Writing compilers is difficult. 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". Somehow, I don't think my manager is going to accept that. And if my manager does make that decision, she'll have hell to pay when she delivers the next release to customers who use that order policy. Especially when she tells them we've been kind enough to give the customer the capability of writing their own order policy, and we suggest that they do so. Of course, it's entirely on their dime to write, test and debug this order policy, but better them than us. This is EXACTLY what has happened with the MOVE opcode in freeform RPG. I'd really like to hear from the manager in charge who made that decision. I'd love to hear why this is a good idea, and then put that answer up in front of the public and see if the public agrees. I want to see how many managers are going to want to hear that they ALL have to duplicate the effort of developing the date conversion MOVE opcode (or any of the other facets of the MOVE operation that the compiler team has decided we don't need). Joe
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.