×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hi Joe,
<snip>
How would you identify which "other service programs" could bind to
those procedures?
</snip>
That's exactly my point - you can't. Hence there is no simulation of package
behaviour because there is no way of knowing what is/isn't in the package.
The simulation can only be true if you treat a single program object as the
only definition of a package. If you do this then you're back to only having
public/private accessors - public via exported subprocedures, private via
data items (exported or otherwise). The only true difference is the "level
of privacy" - module-level or object-level.
Now, if you are asking how I would "propose" to allow package access to
happen then...
Specifying activation group on the export would be one way of allowing a
creator of a service program to restrict access. You could specify other
levels - maybe a signature-level export.
My point is, data items are kept within a program object - period. For any
other program object to access the data, a "public" getter method must be
defined (unless they are defined in the public interface). Once you do this,
there is no way of restricting access except through validation within the
method itself. Now, I haven't got a problem with this. I am simply
highlighting the fact that you can't seemlessly integrate a group of related
service programs without conceding that "other" programs could use your
sub-procs - whether you would like them to or not.
Cheers
Larry Ducie
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.
midrange.com
