Search Path for ::Requires - REXX

Bernie Schneider wrote:

> Can I safely assume that
> it's the same as the search order for external function calls
> (which is well documented)?

Without grabbing the docs, I do believe that is a correct statement.

> Should I just ensure that the files
> are in a directory specified in my PATH environment variable to
> be safe?

That is what I do.

So that the system path would not get overloaded, I have an RFE out for a new variable to be set and checked ahead of PATH sort of like ClassPath for Java. Would be nice to have ooRexx look through
that path for all sorts of external file Rexx things - procedures, ::requires, DLL's, and so forth.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

Remove the upper case letters NOSPAM to contact me directly.

Thanks Michael,

That's a big help to me.

>> So that the system path would not get overloaded, I have an
RFE out for a new variable to be set
>> and checked ahead of PATH sort of like ClassPath for Java.
Would be nice to have ooRexx look
>> through that path for all sorts of external file Rexx
things - procedures, ::requires, DLL's, and
>> so forth.

I like that idea since my PATH is already pretty overloaded. It
would also improve consistency among all of the various types of
external modules that ooRexx may access. It would make it much
easier to package and deploy applications also. I can remember
the days when Rexx was almost completely unmodular. Now with
ooRexx, we have a myriad of means of modularizing our programs:
classes, the macrospace, external function libraries, etc.,
which greatly enhance a programmer's options, but I'm never sure
about the best place for locating the modules. What with the
various types of internal, external, and user defined (via
RexxUtil's SysSearchPath function) searches performed by ooRexx,
I'm always confusing myself.

Thanks again,

-- Bernie Schneider --

The individual has always had to struggle to keep from being
overwhelmed
by the tribe. To be your own man is a hard business. If you try
it, you will
be lonely often and sometimes frightened. But no price is too
high to pay
for the privilege of owning yourself.

Bernie Schneider wrote:
> Thanks Michael,
>
> That's a big help to me.
>
>
>>>So that the system path would not get overloaded, I have an
>
> RFE out for a new variable to be set
>
>>>and checked ahead of PATH sort of like ClassPath for Java.
>
> Would be nice to have ooRexx look
>
>>>through that path for all sorts of external file Rexx
>
> things - procedures, ::requires, DLL's, and
>
>>>so forth.
>
>
> I like that idea since my PATH is already pretty overloaded. It
> would also improve consistency among all of the various types of
> external modules that ooRexx may access. It would make it much
> easier to package and deploy applications also. I can remember
> the days when Rexx was almost completely unmodular. Now with
> ooRexx, we have a myriad of means of modularizing our programs:
> classes, the macrospace, external function libraries, etc.,
> which greatly enhance a programmer's options, but I'm never sure
> about the best place for locating the modules. What with the
> various types of internal, external, and user defined (via
> RexxUtil's SysSearchPath function) searches performed by ooRexx,
> I'm always confusing myself.

A ::requires directive is carried out by the interpreter on behalf of the programmer as a simple
CALL (cf. <http://www.oorexx.org/rexxref/x4441.htm>). In general, the search order can be looked-up
in the docs (cf. <http://www.oorexx.org/rexxref/x16250.htm#XSEARCHO>).

The documentation can be downloaded/viewed as PDF or viewed as HTML-chunks online at
<http://www.ooRexx.org>.

HTH,

---rony

Hi Rony,

Yes, I have studied those pages in the current documentation,
but I just didn't get the part about the ::REQUIRES target being
treated the same as a CALL target for an external routine.
Something about it didn't seem right. I get it now.
Therefore, by inference, the search order for the ::REQUIRES
should be the same as for an external CALL. Thanks for pointing
that out.

Bernie Schneider

The individual has always had to struggle to keep from being
overwhelmed
by the tribe. To be your own man is a hard business. If you try
it, you will
be lonely often and sometimes frightened. But no price is too
high to pay
for the privilege of owning yourself.

-- Friedrich Nietzsche --
"rony" <Rony.Flatscher@wu-wien.ac.at> wrote in message
news:dml85g$2ib8$1@trane.wu-wien.ac.at...
>
> Bernie Schneider wrote:
> > Thanks Michael,
> >
> > That's a big help to me.
> >
> >
> >>>So that the system path would not get overloaded, I have an
> >
> > RFE out for a new variable to be set
> >
> >>>and checked ahead of PATH sort of like ClassPath for Java.
> >
> > Would be nice to have ooRexx look
> >
> >>>through that path for all sorts of external file Rexx
> >
> > things - procedures, ::requires, DLL's, and
> >
> >>>so forth.
> >
> >
> > I like that idea since my PATH is already pretty overloaded.
It
> > would also improve consistency among all of the various
types of
> > external modules that ooRexx may access. It would make it
much
> > easier to package and deploy applications also. I can
remember
> > the days when Rexx was almost completely unmodular. Now with
> > ooRexx, we have a myriad of means of modularizing our
programs:
> > classes, the macrospace, external function libraries, etc.,
> > which greatly enhance a programmer's options, but I'm never
sure
> > about the best place for locating the modules. What with the
> > various types of internal, external, and user defined (via
> > RexxUtil's SysSearchPath function) searches performed by
ooRexx,
> > I'm always confusing myself.
>
> A ::requires directive is carried out by the interpreter on
behalf of the programmer as a simple
> CALL (cf. <http://www.oorexx.org/rexxref/x4441.htm>). In
general, the search order can be looked-up
> in the docs (cf.
<http://www.oorexx.org/rexxref/x16250.htm#XSEARCHO>).
>
> The documentation can be downloaded/viewed as PDF or viewed as
HTML-chunks online at
> <http://www.ooRexx.org>.
>
> HTH,
>
> ---rony