Ok, I've come up with a compromise. Packages are still loaded and maintained on a process basis, but each interpreter instance will maintain a list of packages that is used by code running in the instance and will ensure that the prologue code gets run when the package is first requested by the instance. Since .local is also maintained on an instance basis, this should fix the behavioral problems you're seeing. And the code refactoring required to implement this fixed a couple of things I was not happy about in the package manager code, so this is definitely a win-win.
Rick On Sun, Apr 5, 2009 at 9:22 AM, Rony G. Flatscher <rony.flatsc...@wu-wien.ac.at> wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
