|
Scott, I get what you are saying, but I also understand where Albert is coming from. Maybe you can help get me up to speed, because I would really like to take advantage of this. I can see many uses for it. First, I think that Albert (I'm not picking on you, this is just an example) and others have a successful paradigm that has worked for them and desire a good example of how they can benefit from overloading. After reading Albert's and your postings I thought of a magazine article (or maybe a series of them) titled "The last date routines you will ever need" or something like that. I remember at that time thinking they truly ARE the last thing I would WANT! BTW, this was before date data types, but the whole concept was a whole bunch of little routines that did something with dates supported by another whole bunch of routines that converted your input into an agreed upon date format. Under that concept, it would be normal to take your input and call one of several routines to convert your data to the agreed upon format then call the routine that actually performed the desired function. Oh, I almost forgot, then you called another routine to convert the results into the format you wanted to work with. And if the format of your input changed, well ... go fish ;) Now here is where I'm lacking on education. Let's say I want to write GetCustInfo and I want to pass a name (alpha) or a customer number (11,0S) or a phone number (also 11,0S). I still wind up writing, and using within my program, GetCustInfoByName, GetCustInfoByNumber, GetCustInfoByPhone or do I just write GetCustInfo(NAME:keyedName) or GetCustInfo(NUMBER:keyedNumber) and GetCustInfo(PHONE,keyedPhone)? Or can I write GetCustInfo(keyedName) GetCustInfo(keyedNumber) and GetCustInfo(keyedPhone) and GetCustInfo can by divine province tell the difference? Now each customer has a unique number, but I may have more than one ACME in my list. So get by name has to be able to return a list of possibilities if there is more than one or just the info if there is only one. Again this may be a bad example. But a true, real world, working example would help a whole bunch for me. Scott Mildenberger wrote: > Albert, > > Using your example below, why should every program that needs to use DaysDur > have to worry about converting to a common format. It is just extra code > that every calling program needs that can be eliminated. <<snip>> > > At least in my mind, it would be nice that anytime > I wanted to calculate a duration in days I just call DaysDur and pass my > dates, no worrrying about how the date has to be formatted and doing that > conversion. > > I do think overloading can be really useful in some cases, and of course > like any tool it can be abused. > > Scott Mildenberger > > > -----Original Message----- > > From: York, Albert [mailto:albert.york@nissan-usa.com] > > Sent: Thursday, May 10, 2001 12:20 PM > <<snip>> > > > > I would prefer to have one procedure and do any necessary > > conversion in the > > program. > > > > For example: > > > > DDaysDur PR 5I 0 > > D CharDate1 8A > > D CharDate2 8A > > > > C Eval Cdate1 = Ndate1 > > C Eval Days = DaysDur(Cdate1: Cdate2) > > +--- | 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.