|
>> Actually I was thinking much more in the lines of the VisualAge products. I >don't >> want DDS specs in the RPG. The concept of a bindable object is more in line >with >> my thinking. In fact, I would like the interface to be like the VA >environment (use >> BIFs to control color, underlines, messages, etc). That way the "screen" >becomes >> lower level (like MI vs RPG) and to generate a different protocol (5250 vs >GUI for >> example) is a function of the OS and not a compiler. Maybe if we had been >doing >> this for a few years, we would be ready for the OO world. > How would this make us ready for the object oriented world? Isn't a display >file a discreet > object that, in theory, may be reused? Or are we assuming by OO we mean GUI >instead? I was actually thinking in smaller terms. I will use a date field for an example. In the past, I would create a date field in a field reference file as 6-digits with an edit code of ' / / '. I would then reference this date field in a physical file whenever I needed a date field. I would then reference the date from my physical whenever I used it on a display file. Each program would then have to include code to work with and validate the date field. I would want it stored as YYMMDD so I could sort/select on it, but I wanted it displayed as MM/DD/YY on screens and reports. The new date data type does this automatically, plus it allows us other capabilities such as date math. The date format and text description of the date field are properties. I would consider the date an object. The display file would be an object that contained "smaller" objects. I was using BIFs (see earlier message) to modify the properties. A date is one example. Now if we could create our own objects that worked similar to dates, this is what I meant by OO. I could create an object for Zip Code. All of the business rules for a zip code would reside in the object. I could change a property to control whether the zip code must be a 5-digit, Zip+9 or International code. It would automatically validate a zip code just like a date data type does for a date. I could create any functions appropriate for this object and all references to the object would inherit them (this is really available using subprocedures, binding, service programs, etc). Is a display file a discrete, reusable object? Yes. Could it be an object that houses a collection of "smaller objects"? I think so. Joe Teff Information Technology Consultant +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-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.