Re: Service programs

OK - je compris. I'm clearly a little slow today.

I would use an integer or some other handle - actually for the very reason you stated. Or rather an extension of that reason namely I would add the phrase "and must not be able to obtain and mess with the data" to your comment "I'm talking about the Caller *not* knowing about the data. And more to the point, the Caller *shouldn't* need know about the instance data."

If the caller has a pointer it can be can be dereferenced. If the caller shouldn't know or care about the data it should also not be able to _see_ the data if encapsulation is really important. With an integer handle the data can only ever be referenced in the architected manner. With a pointer you lose that protection.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On May 17, 2017, at 2:53 PM, Hiebert, Chris <chris.hiebert@xxxxxxxxxxxxxx> wrote:

-- The service program always has to be aware of the format of the data no matter how it is transmitted...

Jon, I'm not talking about the service program knowing about the data.

I'm talking about the Caller *not* knowing about the data.
And more to the point, the Caller *shouldn't* need know about the instance data.

The callers should be using specialized procedures to return the specific information they need.

What would be your alternative to using a pointer as an instance variable?
That also does not require a recompile when the Service Programs change what is contained in the instance data?
Keep in mind, the instance data is only used by the Service Program, not the callers of the procedure.


Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD