#include <TCLCommandPackage.h> ... typedef std::list <CTCLProcessor*> CommandList; typedef CommandList::iterator CommandListIterator; class CTCLCommandPackage : public CTCLInterpreterObject { public: CTCLCommandPackage (CTCLInterpreter* pInterp, const std::string& rSignon=std::string("Unnamed pkg")); CTCLCommandPackage(CTCLInterpreter* pInterp, const char* pSignon = "Unnamed pkg"); virtual ~ CTCLCommandPackage ( ); CTCLCommandPackage (const CTCLCommandPackage& aCTCLCommandPackage ); CTCLCommandPackage& operator= (const CTCLCommandPackage& aCTCLCommandPackage); int operator== (const CTCLCommandPackage& aCTCLCommandPackage); std::string getSignon() const; CommandList getCommandList() const; protected: void setSignon (std::string am_sSignon); public: void Register () ; void Unregister () ; void AddProcessor (CTCLProcessor* pProcessor); void AddProcessors(CommandList& rList); CommandListIterator begin (); CommandListIterator end (); };
Extensions to Tcl often come in a set of related commands. These commands
may require access to a common set of services. The CTCLCommandPackage
along with the CTCLPackagedCommand
provide a pair of base
classes that facilitate the construction of such commands.
The pattern to follow to derive class from CTCLCommandPackage
This class defines and implements common services for the related commands.
The constructor of the derived class will also create instances of
classes derived from CTCLPackagedCommand
. These objects
define and implement the related commands. These command processors will be
added to the package via AddProcessor
, and
AddProcessors
.
When the CTCLCommandPackage
::Register
function is called, all of the commands added to the package will be
registered as well. When a command processor is invoked, it can call its
getMyPackage
member function to obtain a pointer to the
owning package and therefore access to the services this package provides.
CTCLCommandPackage
(CTCLInterpreter*pInterp
, const std::string&rSignon
=std::string("Unnamed pkg"));CTCLCommandPackage
(CTCLInterpreter*pInterp
, const char*pSignon
= "Unnamed pkg");CTCLCommandPackage
(const CTCLCommandPackage&aCTCLCommandPackage
);
Constructs instances of the package. pInterp
is a pointer
to the interpreter object on which these commands will be registered.
signon
is a text string that will be emitted to
stderr when the package is asked to register its commands.
This string is typically a credit or copyright notice for the package. It can
be empty if the user desires.
The first and second form of the constructor only differ in how the signon message is passed. The final form of the constructor is a copy constructor. While copy construction is legal it is anticipated that this will not normally be used as command packages are usually singleton objects.
std::string getSignon
() const;
Retrieves the signon string from the current object.
CommandList getCommandList
() const;
Retrieves the list of commands that are managed by this package.
voidsetSignon
(std::stringam_sSignon
);
Allows derived classes to set the signon string after construction is complete.
voidRegister
() ; voidUnregister
() ;
Regsiter
registers all of the commands in the package
with the package's interpreter. Unregister
unregisters
these commands. It is therefore not advisable to change the set of commands in
the package between registration and unregistration.
voidAddProcessor
(CTCLProcessor*pProcessor
); voidAddProcessors
(CommandList&rList
);
These functions add command processors to the package. Any type of processor
can be added to the package, however usually CTCLPackagedCommand
derived objects are in order to provide a mechanism to access the package services.
pProcessor
is a pointer to a single processor while
rList
is a reference to a list of such processors.
CommandListIteratorbegin
(); CommandListIteratorend
();
Returns STL list iterators to the beginning and off the end of the
set of command packages.
List iterators behave roughly like pointers. In this case, pointers
to CTCLProcessor*
. Incrementing an interator
'points' it to the next item in the list. A full discussion of STL iterators
is well beyond the scope of this man page. See references below.