Hi there,
Rick McGuire wrote:
> You have misunderstood what this thread was about. Mike's programs
> were unaffected, oodialog has already been reworked to remove an old
> hacky way to get around the old behavior. This really only becomes an
> issue for programs that stuffed things into .local to get around how
> ::requires used to work AND those programs are relying on the
> information in .local persisting between RexxStart() invocations.
In addition to the ".local-problem" there is one more possible problem:
if the external function library needs to be configured from the Rexx
program for each RexxStart(), this is in the current drop not possible!
E.g. in the case of BSF4Rexx the external function library gets
configured by the initialization/prologue code in BSF.CLS. If the
"initialization"/"prologue" code is not executed, then the Rexx programs
cannot function correctly anymore! (The same is true for UNO.CLS which
adds the support to script the OpenOffice.org applications, sitting on
top of BSF.CLS.)
---
It is impossible to say how many applications are deployed in companies
which invoke Rexx via RexxStart() because they use Rexx as a scripting
language for their applications. If they dispatch ooRexx programs that
deploy the requires-directive, then they may depend on the current
behaviour of GA-ooRexx (the behaviour has been there since the IBM
Object REXX days), in that after following all directives the
initialization/prologue code gets run, which indeed does also carry out
all sort of initializations.
In such use-cases it may not be possible to replace the
requires-directive with a call being the very first statement in the
initialization/prologue code, because it may be the case that the
directives refer to public classes and public routines in the required
programs !
Now, the current (pre 4.0) behaviour of files/programs/packages being
required via the requires-directive has been a constant cause of
confusion (each requires causes in the scope of that program that
required public classes are scoped class object instances that are not
equal to the class object instances of other programs having required
the same package!), hence coming up with a solution that truly allows a
required program/package to be required globally, i.e. any other
requires would refer to the already globally (cached) required
file/package. Skimming over the current source code of ooRexx 4.0 one
can tell that a lot of effort has been invested in this desired (and
very appreciated!) behaviour available only in ooRexx 4.0.
---
Thinking about this particular problem "from a distance" of a few days,
weeks, it seems that the real problem currently is that the new global
behaviour is currently set out to be the default behaviour for ooRexx
4.0! This therefore may jeopardize all ooRexx programs, that have
exploited the "classic" requires-behaviour, needing the
initialization/prologue part to be run for each RexxStart().
Hence, how about the following idea?
* Let the requires-directive behave as in all previous versions of
ooRexx (semantics of "context->CallProgram()"?), e.g.
::requires someRexxPackage.rex /* executes as in all previous
versions of ooRexx */
* allow /a new keyword on the requires directive/ that tells ooRexx
4.0 to use the new behaviour (semantics of
"PackageManager::loadRequires(...)"), e.g. if the new keyword is
named "global" (maybe there are more meaningful keywords like
"cache", "loadonce", "singleton", etc.)
::requires someRexxPackage.rex *global */* global keyword causes the
package to be globally cached */
This would allow all pre-ooRexx 4.0 programs with requires-directives to
execute as in the past, hence backward compatibility in this regard is
ensured.
It also would allow to start to use the new (preferable) behaviour if
the ooRexx programmer wishes to do so (and I think, if ooRexx
programmers realize how great the new behaviour is, that they will
eventually adopt their programs to do so; there may be - probably rare -
cases where this would not be possible, but then that would not be a
problem either as the "old" behaviour is available as well). In
addition, having seen the new C++ APIs new libraries and packages can be
devised that would easily be able to exploit "globally cached packages".
HTH,
---rony
------------------------------------------------------------------------------
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
