A package is self-contained and completely defined by the table within the package. There's no way to dynamically change those tables, so the best solution for that level of control is to use a different dll stub for ones you don't wish to have loaded for an environment.
The "loader" entry you refer to is just an initialization routine that Rexx will call when your package is loaded. It doesn't control the registration of any of the package entries. Rick On Mon, Mar 9, 2009 at 12:59 PM, Rony G. Flatscher <rony.flatsc...@wu-wien.ac.at> wrote: > > Rick McGuire wrote: >> Well, it your expectation is a complete running program, then this >> will have to wait a while until I finish up some other things (many of >> which happen to be different sample programs). If all you want is >> answers to some of these questions, then I probably give you a reply >> with the code snippets involved later this evening. >> > It would not be urgent at the moment (being tied down with University > matters, start of semester, classes, meetings), if you can come up with > complete running programs eventually, that would be fine enough. > > But maybe one question, not addressed by the suggested nutshell > examples: would it be possible to have different sets of external APIs > loaded, depending on the use-case (e.g. for BSF4Rexx the external > functions BSFLoadJava() and BSFUnloadJava() should not be available, if > invoked via Java). This seems to be implied via the "RexxPackageLoader > loader; // the package loader" entry in the RexxPackageEntry structure; > however, it would be very helpful to learn what would be necessary to > implement a RexxPackageLoader on the own, and what responsibilities one > would have to fulfill. But maybe there is an alternative means of > indicating which routines should be made available and which ones should > not at runtime. Again, there is no urgent need for this, just curiosity > (and a need once starting to adapt BSF4Rexx to the new APIs, before > extending it). > > ---rony > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
