Rick McGuire wrote: > Sorry, I am adamantly opposed to any effort to preserve that old > behavior. It was the cause of no end of problems, including most of > the hacks you're now citing as instances of the problems. At this > point in the project, what you're proposing will be an incredibly > disruptive change to the code base that I'm not willing to make. If > you are willing to put in the time and effort to come up with a patch > that demonstrates this change, we might consider it. It, however, > needs to be done quickly, as I'm also not willing to delay the release > of 4.0 to wait for it. > O.K., I'll do my best, but it'll take some time for me to come even close to be able to do that.
---rony > On Sun, Apr 5, 2009 at 8:55 AM, Rony G. Flatscher > <rony.flatsc...@wu-wien.ac.at> wrote: > >> 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
