RE: Parameter prototype question

Opting to remove Const for this reason alone doesn't make any sense to me. Especially considering what you've just learned about it. Now you know, and knowing's half the battle....

Personally, every procedure parameter I create starts with Const. I remove it if it's an input/output (or output only) parameter. I replace it with Value if the parameter might change, but that value shouldn't be returned to the caller. To me, the value in knowing if a parameter will be changed by a procedure or not is invaluable. Well worth taking the extra second to hit ctrl-space in WDSCi to see the size of the field being passed and again to see the expected parameter sizes (although I really do wish WDSCi would show us the decimal precision).

You can search the archives to find a wealth of information about Const. Sure, there's more to it than meets the eye (under the covers it can convert from one data type to another, etc), but it's worth learning about.

And just for one more: transform and roll out.

-Kurt



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Friday, May 14, 2010 9:44 AM
To: RPG programming on the IBM i / System i
Subject: RE: Parameter prototype question

Today I learned that protoyped procedure parameter checking must be done manually when using CONST or VALUE.
Thanks.

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Simon Coulter
Envoyé : vendredi 14 mai 2010 09:22
À : RPG programming on the IBM i / System i
Objet : Re: Parameter prototype question


On 14/05/2010, at 4:06 PM, David FOXWELL wrote:

Well, now I'm wondering about the value of using CONST at

all. I don't

see that that's much protection against anything unless you don't
test. It seems we only really need it to indicate which

parameters are

intended to be used as input only. The kind of problem I've had
without using CONST could be waiting to happen in many other
procedures.

Pah! The compiler can't protect you from stupidity. The
problem was caused entirely by you trying to stuff 9 pounds
in a 7 pound bag and not expecting it to overflow i.e., not
paying attention to what you were doing. Sure, without CONST
or VALUE the compiler would have caught the mismatch but
consider the reverse situation where you might want to pass a
smaller value or a different data type or a literal; in all
these cases the compiler will assist you by verifying the
base data type (i.e., numeric vs. character vs. date) is
correct and will convert the actual type to the expected
type. This makes the procedure far more flexible and useful
than forcing the consumer to define an exactly matching data type.

Note that you would have received exactly the same error if
you'd tried an arithmetic EVAL that resulted in a value too
large for the variable e.g. small = EVAL
some-bloody-huge-arithmetic-expression. Do you expect the
compiler to protect you from that situation too? Both of
these cases are run-time errors for which proper exception
handling can be implemented to at least catch and notify you
of the problem.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------



--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.