|
On 30/04/2010, at 7:04 AM, MattLavinder@xxxxxxxxxxxxxxxxxxx wrote:
Been looking through the IBM i 7.1 Technical Overview. Do my eyesYes, it's true, and even then you may not need to include a prototype
deceive
me or does this thing say that prototypes will be optional for
procedures
that are not exported in IBM i 7.1?
for exported procedures in the defining module.
This would be fantastic news.I wouldn't go that far. It's useful in that the compiler can generate
internal prototypes for verifying internal procedure calls but all it
does is save a bit of typing i.e., copy/paste the interface, change PI
to PR, done.
Here is the text from page 391 of the document, but it is only aPoint 3 is worded interestingly:
draft at
the moment so the page number could change.
-----
Optional prototypes (see Example 16-6)– If a program or procedure is
not
called by another RPG module, it is optional to specify the prototype
-----
Here is the sample code they had.
http://code.midrange.com/fed74afc36.html
A program or procedure that is never intended to be called from RPG
Intent? How will they know my intent? I'll have to wait for access to
VRM710 to experiment but the documentation seems a little confusing.
The "What's New" section of the RPG Reference (page xiv) says that a
prototype is not needed for an exported procedure that is intended to
be called from a different programming language.
The "Prototypes and Parameters" section (page 153) says "If the
procedure is called from a different RPG module, the prototype must be
explicitly specified in both the calling module and the module that
defines the procedure.".
Note the use of BOTH in the above quote. Note the apparent conflict
between the two statements: A prototype is not needed in the defining
module unless it is intended to be called from RPG. Why would that
matter? Either a prototype is needed for an exported procedure or it's
not. The intended use doesn't matter.
How will they know my intent? It's easy for a program interface--
prototyping just becomes optional in the defining module. If I choose
to call the program via a prototyped call from another program I will
need to create a prototype for inclusion in that other program. A bit
harder for (and probably impossible as worded) for procedures. I might
write a procedure in RPG (perhaps date conversion stuff because RPG
has good support for this) and export it and never intend to call it
from RPG but only from C (because it has no support for date data
types). Seems to me a prototype in this case is also optional in the
defining module. If I later choose to call this from RPG I will need a
prototype for the consumer but it will/should not be required in the
defining module.
Whether an exported procedure is consumed by another RPG module is
something that cannot be known until bind-time by which time it is too
late for the RPG compiler to enforce required prototypes. That is,
they cannot glean my intent.
Therefore it seems to me that:
Prototypes are required only for prototyped program calls (well,
duh!) or procedure calls where the procedure resides in a different
compilation unit.
Which would be a much simpler way of stating things.
Wow. Pretty exciting.Nah ... I think some of other enhancements are more interesting e.g.,
Passing any type of string parameter, or the RTNPARM keyword--although
I suspect that will only prove useful in an RPG to RPG call which
would make it much less useful to me.
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 / \
--------------------------------------------------------------------
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.