Re: Service programs, procedures, not sure what to do

I guess we're getting a little off track, but it's a neat discussion. :)

My main point of sharing that was because over the years I've done things
many different ways and continue to evolve (in 5 years I'll probably look
at this and think "wow, I could have done it this other way instead!").

I think the OP was asking about printing something for a customer and doing
that from a procedure.

something like

printOrderHistory(custno:startdate:enddate:[otherparms]);

My point was instead of guessing at which parameters the proc will need
(and inevitably change), use setters.

set('customer':custno)
set('beg_date':begdate)
set('end_date':enddate)
printOrderHistory()

So, if down the road they want the option to only print open orders you can
add:
set('order_type':type) //open, closed, both

Simple change to the internals of the "set()" proc, nothing more. Instead
of needing to change the prototype to printOrderHistory(), or create a new
proc with the new parameter.

To me, it's just easier and cleaner than trying to use omit, nopass, etc
and changing the prototype for each change to the parameter list that will,
inevitably, come along.

Brad
www.bvstools.com



On Thu, Jan 8, 2015 at 9:13 AM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Thu, Jan 8, 2015 at 9:06 AM,
<j.beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

My code was sort of an equivalent of how you would do it in Java:

MailData maildata = new MailData();
maildata.setValue('fromAddress':'jclarkson@xxxxxxxxxxx');
(or maildata.setFromAddress('jclarkson@xxxxxxxxxxx');)
maildata.send();

The reason I do it that way is that in my scenario the caller owns the
memory. In your scenario the service program owns the memory. In practice
it probably won't make much of a difference, but I think the caller

should

be the owner of the memory.

Well, of course RPG's support for class-based object-oriented
programming is weak. I personally think treating the service program
as an object (more or less like Brad suggests) is closer to the Java
model, since the data and the methods (procedures) belong with the
object, not the caller.

That being said, you bring up a good point:

And in my scenario it would be possible to
have more than one MailData 'object', in your scenario it is a singleton.

I have to admit, I don't have much experience or practice with service
programs, but if I understand correctly, it would indeed look like a
singleton to its caller. However, can multiple callers each have
their own "instance" of the service program's global data? If so,
then you can still (with further scaffolding; maybe another service
program to wrap the MailData service program?) get your multiple
MailData instances.

It's probably all moot, though. I would think the normal use case is
just to create one e-mail, send it, then create another e-mail, and
send that, etc. I think you tend not to need multiple concurrent
instances.

John Y.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.