RE: OO in RPG -- RPG400-L

It is clear that unless a program uses a service pgm then compiling and
binding essentially occur at the same time. The fact that a service pgm is
implemented through late binding, which occurs the time the pgm is
activated, might be construed as subtle but the point I make is that, at the
time the code is executed, all pointer references must have been previously
resolved, essentially by hard coding them. In this context the term dynamic
therefore has a subtle meaning.

Peter  

-----Original Message-----
From: Scott Klement [mailto:klemscot@klements.com]
Sent: Tuesday, December 05, 2000 6:51 PM
To: 'RPG400-L@midrange.com'
Subject: RE: OO in RPG



The address of the procedure doesn't need to be known at compile time, 
it needs to be known at bind time. :)

The difference is subtle, but its useful.  In particular, I have service 
programs that get data and need to write it somewhere, but depending on
the application, where they write it can be different.  So I pass them
procedure pointers, and they call the given procedure to write the data.

If I want to write it to a stream file, for example, I can pass the
address of the IFS "write" procedure.  Similarly, I can provide my own
procedure, in the same format as "write", if I want to do something else
with it. 

I don't need these to be "truly dynamic", and I appreciate the speed
improvement that binding them gives me -- but at the same time, I don't
want to recompile the service program for every new application that uses
the routines -- and this is why its important that the addresses are
resolved at bind time.

Make sense?


On Tue, 5 Dec 2000, Peter Connell wrote:

> Jon has already alluded to the fact that the standard use procedure
pointers
> only gives the illusion of dynamic procedure calls. In other words the
> procedure call is dynamic only in the sense that it points to a procedure
> whose address was resolved at compile time or when the program was
activated
> in the case of a service pgm, unlike the old dynamic calls that are
resolved
> only at runtime. It means that you can benefit by coding a call using a
> procedure pointer but you still have to include code that initializes all
> the pointers by assigning them the address of the corresponding procedure.
> So you are in effect still hard coding all the procedure calls.
> 
> To obtain a truly dynamic procedure call that is not known at compile time
> you must you the special API's that permit you to force the activation of
a
> service pgm and provide access to the procedures within.
> 
> Cheers, Peter
> 

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

This communication is confidential and may be legally privileged. 
If it is not addressed to you, you are on notice of its status. 
Please immediately contact us at our cost and destroy it.  
Please do not use, disclose, copy, distribute or retain any of it 
without our authority - to do so could be a breach of confidence. 
Thank you for your co-operation.  
Please contact us on (09) 356 5800 if you need assistance.
+---
| 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
+---