× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Peter,

> While you don't have to test for every possible combination of data type
and
> parameter count, you do have to define every possible valid combination by
> creating a prototype for it, at least you did in the example.

True, but the number of valid combinations is (in my experience) always less
than the number of possible combinations, therefore you have less work to do
overall.

> I was looking
> for some benefit on the calling program side like fewer lines of source
> code. More work in the service program though I suppose, but that's ok --
I
> only have to write that once.

I don't think I understand what you're saying, because I do see the benefit
on the calling side. From the perspective of the calling procedure, the same
advantage is presented by both of our methods.

> The main example of overloading that made sense to me was the + binary
> operator being used for adding numbers or concatenating strings. That
would
> fit my idea of a fixed number of parms, but as you say, the compiler would
> not be able to catch any invalid combinations of type. On the other hand,
> with
>
>     DDaysDur          PR             5I 0  OPDESC
>     D Date1                           *
>     D Date2                           *
>
> it would be perfectly reasonable to use
>
>     c        eval days = DaysDur(charDate1: numericDate2)
> or  c        eval days = DaysDur(dateDate1: dateDate2)
>
> since the service program could use the operational descriptors to
determine
> which parameter was what and convert them accordingly before doing the
> actual days duration calculation.

The problem is that it would also be perfectly reasonable to do the
following:

c     Eval Days = DaysDur(CharSize2: DecimalNum)
c     Eval Days = DaysDur(Boolean: Timestamp)
c     Eval Days = DaysDur(Graphic: USC-2)

... and so on.

> And I would not have to create a bunch of
> prototypes for every possible valid combination since pretty much anything
> would be valid.

Even if we had full operational descriptor support (which we don't), it
would be more work than it's worth. We only need look to history for
evidence of this. What you're talking about is easily achievable in a
language like Java by declaring each input parm as type Object. Since
everything (except native data types) in Java inherits from Object, this
would allow you to pass any combination of object types in as parameters.
Yet we rarely ever see this, because it's always less work to define a
handful of interfaces, than it is to deal with every possible combination
that could conceivable be thrown at you.

> Now supposing that DaysDur was written so that if you only provided one
> parameter it would default the other parameter to the system date or
> something, it could simply check %parms. But I suppose there are other
> situations where you would want the compiler to validate the parameters
> before they're passed to the service programs.

The irony here is that with overloaded functions, you don't need to "simply"
check %Parms at all. :)

> It's been a long time since I wrote a program that used the operational
> descriptors, but I believe they do tell you the type of field being passed
> don't they?

Not entirely. As of V4R5, they're only good for CHAR and GRAPHIC types. This
is something that many of us have been asking for improvements to, but as I
understand it, Rochester needs to provide the some additional support in the
OS before the RPG team can deliver the improvements.


John Taylor
Canada


+---
| 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.