

o  Choose an appropriate namespace in the Math::Symbolic::Custom::* hierarchy or if you desparately wish, somewhere else. 
o 
Create a new module (probably using h2xs AX MODULENAME) and put the
following lines of code in it:
# To make sure were cooperating with Math::Symbolics idea of # method delegation. use Math::Symbolic::Custom::Base; BEGIN {*import = \&Math::Symbolic::Custom::Base::aggregate_import} our $Aggregate_Export = [ # Put the list of method names to be exported. /]; 
o 
Think well about the naming of your exported methods. Answer the following
questions:
Does the name start with ’is_’, ’test_’, ’mod_’, ’apply_’, ’contains_’, or ’to_’? If not, find a suitable name that does. Does the name clash with any of the methods exported by Math::Symbolic::Custom::DefaultTests, Math::Symbolic::Custom::DefaultMods, or Math::Symbolic::Custom::DefaultDumpers? If so, please consider choosing a different name. Does the name map to the idea behind the method prefix (’is_’, ...)? Only methods starting with one of the prefixes listed above can be delegated. Any others will never be called. The idea behind delegating methods with several prefixes is to provide for a reasonable choice for naming methods. ’is_’ and ’contains_’ are meant to be used for accurate tests like is_constant. ’test_’ is meant for all tests that either make use of heuristics or can’t be fitted into either ’is_’ or ’contains_’. The prefixes ’mod_’ and ’apply_’ are meant for use with methods that modify the Math::Symbolic tree. Finally, the prefix ’to_’ is meant to be used with conversion and output methods like ’to_latex’ or ’to_string’. (Though as of version 0.122, to_string is implemented in the core Math::Symbolic modules.) 
o  Make sure you document exactly what your methods do. Do they modify the Math::Symbolic tree inplace or do they clone using the new() constructor and return a copy? Make sure you mention the behaviour in the docs. 
o  Consider packaging your extensions as a CPAN distribution to help others in their development with Math::Symbolic. If you think the extensions are generic enough to be a worthwhile addition to the core distribution, try sending your extensions to the Math::Symbolic developers mailing list instead. 
o  Load your extension module after loading the Math::Symbolic module. 
o  Start using your custom enhancements as methods to the Math::Symbolic trees (any term types). 
o  Send bug reports and feedback to the Math::Symbolic support mailing list. 
Please send feedback, bug reports, and support requests to the Math::Symbolic support mailing list: mathsymbolicsupport at lists dot sourceforge dot net. Please consider letting us know how you use Math::Symbolic. Thank you.If you’re interested in helping with the development or extending the module’s functionality, please contact the developers’ mailing list: mathsymbolicdevelop at lists dot sourceforge dot net.
List of contributors:
Steffen MXller, symbolicmodule at steffenmueller dot net Stray Toaster, mwk at users dot sourceforge dot net Oliver EbenhXh
New versions of this module can be found on http://steffenmueller.net or CPAN. The module development takes place on Sourceforge at http://sourceforge.net/projects/mathsymbolic/Math::Symbolic::Custom::Base Math::Symbolic::Custom::DefaultTests Math::Symbolic::Custom::DefaultMods Math::Symbolic::Custom::DefaultDumpers
perl v5.20.3  MATH::SYMBOLIC::CUSTOM (3)  20130617 
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.