× 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.



On Tue, Oct 8, 2019 at 3:10 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Because the return type/size has to be the same on _all_candidates. So I guess this is just defined as a baseline to make it obvious to anyone studying the proto that no matter what routine does the work, a VarChar(100) will be returned.

Then we're back to "double up on the prototypes, no matter what".

If it must be the same on all candidates, then either

(1) define the return value just on FORMAT (define it once, the
compiler propagates it to the rest), or

(2) define the return value just on each of FORMAT_* (define it three
times, the compiler checks that they are all the same, and propagates
it to FORMAT).

The first option is the least repetitive and least error-prone.

Any arguments along the lines of "but I want to be able to read it and
know what everything is without jumping around" undermine the D-spec
concept and in effect argue for going back to in-line definitions, or
even worse, argue for *more* copy-pasting.

There is a reason why most languages strive to reduce the repetition
to a minimum. RPG seems to have the pattern of "whoa, that's too hard
to figure out how to implement, let's make the programmer type extra
(or copy-paste!) to make things simpler for us compiler writers".
Maybe this is sold under the guise of providing "extra checking" but
really it's pointless extra hoops. As with the pointlessly duplicated
prototypes for same-module procedures, eventually they will realize
that they can implement it after all.

I can tell that some folks would rather the compiler team just hunker
down and take extra time if needed to figure it all out and get it
right the first time. An RFC period (proposed by someone else) would
actually be a great boon for this. I mean, sometimes the commenters
simply don't have enough information about the true difficulty of
implementing something. It will always be the implementers'
prerogative to reject all comments. But for the cases where the
commenters have a point, the RFC process would help reduce the chance
that good ideas are missed.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.