Rick McGuire wrote: > While working on test cases for the new exit handlers, I realized that > I've left a somewhat gaping hole in the new APIs. We've got excellent > coverage for functions and methods, we have new versions of the exits > that give access to the oo APIs ok. The one area we've neglected is > the subcommand handlers. The legacy subcommand handlers are > inherently a string-based API and there's no access to the expanded > API capabilities we offer in the rest of the places. My first thought > was "leave it for a future release", but I have this suspicion it > really should be addressed now. > > I think I'd like to do this the same way the new exits were > implemented. The new exits don't rely on a registration mechanism, > they are specified via an option argument passed to the > RexxCreateInterpreter() API. These exits are specified by address > only, and apply to everything that runs in that interpreter instance. > I'd like to do something similar with subcommand environments, using > an option that points to a list of additional subcommand environments > that make up part of the interpreter instance. The new subcommand > handlers would have the following signature: > > RexxObjectPtr RexxEntry CommandHandler(RexxExitContext *, > RexxStringObject address, RexxStringObject command); > > This is a fairly simple structure. The address name and command are > strings, the return value can be any object (which means a command > environment could return something other than a string as a return > code, if desired). The context pointer is the Exit context. The > RexxCallContext contains a number of functions that just don't apply > to commands, so that won't work. The Exit context contains the > appropriate functions. The other option would be to create a > RexxCommandContext...I'm not sure that's justified, but I can be > convinced to implement it that way people think that's the way to go. > The command context would have the same functions defined for the Exit > context. > > Rick > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > I don't think another context is needed for this. Unless someone can come up with some subcom exit only methods. But off the top of my head I can't think of any specialized methods I would need for a subcom handler.
David Ashley ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
