Ewan Birney


Bio::Root::RootI - Abstract interface to root object code


  # any bioperl or bioperl compliant object is a RootI 
  # compliant object

  $obj->throw("This is an exception");

  eval {
      $obj->throw("This is catching an exception");

  if( $@ ) {
      print "Caught exception";
  } else {
      print "no exception";

  # Using throw_not_implemented() within a RootI-based interface module:

  package Foo;
  @ISA = qw( Bio::Root::RootI );

  sub foo {
      my $self = shift;


This is just a set of methods which do not assume anything about the object they are on. The methods provide the ability to throw exceptions with nice stack traces.

This is what should be inherited by all bioperl compliant interfaces, even if they are exotic XS/CORBA/Other perl systems.

Using throw_not_implemented()

The method throw_not_implemented() should be called by all methods within interface modules that extend RootI so that if an implementation fails to override them, an exception will be thrown.

For example, say there is an interface module called FooI that provides a method called foo(). Since this method is considered abstract within FooI and should be implemented by any module claiming to implement FooI, the FooI::foo() method should consist of the following:

    sub foo {
        my $self = shift;

So, if an implementer of FooI forgets to implement foo() and a user of the implementation calls foo(), a Bio::Exception::NotImplemented exception will result.

Unfortunately, failure to implement a method can only be determined at run time (i.e., you can't verify that an implementation is complete by running perl -wc on it). So it should be standard practice for a test of an implementation to check each method and verify that it doesn't throw a Bio::Exception::NotImplemented.


Functions originally from Steve Chervitz. Refactored by Ewan Birney. Re-refactored by Lincoln Stein.


The rest of the documentation details each of the object methods. Internal methods are usually preceded with a _


 Purpose   : generic instantiation function can be overridden if 
             special needs of a module cannot be done in _initialize


 Title   : _create_object()
 Usage   : $obj->create_object(@args)
 Function: Abstract method which actually creates the blessed object reference
 Returns : Blessed object (hashref, arrayref, scalarref)
 Args    : Implementation-specific


 Title   : throw
 Usage   : $obj->throw("throwing exception message")
 Function: Throws an exception, which, if not caught with an eval brace
           will provide a nice stack trace to STDERR with the message
 Returns : nothing
 Args    : A string giving a descriptive error message


 Title   : warn
 Usage   : $object->warn("Warning message");
 Function: Places a warning. What happens now is down to the
           verbosity of the object  (value of $obj->verbose) 
            verbosity 0 or not set => small warning
            verbosity -1 => no warning
            verbosity 1 => warning with stack trace
            verbosity 2 => converts warnings into throw
 Example :
 Returns : 
 Args    :


 Title   : debug
 Usage   : $obj->debug("This is debugging output");
 Function: Prints a debugging message when verbose is > 0
 Returns : none
 Args    : message string to print to STDERR


 Title   : deprecated
 Usage   : $obj->deprecated("Method X is deprecated");
 Function: Prints a message about deprecation 
           unless verbose is < 0 (which means be quiet)
 Returns : none
 Args    : Message string to print to STDERR


 Title   : verbose
 Usage   : $self->verbose(1)
 Function: Sets verbose level for how ->warn behaves
           -1 = no warning
            0 = standard, small warning
            1 = warning with stack trace
            2 = warning becomes throw
 Returns : The current verbosity setting (integer between -1 to 2)
 Args    : -1,0,1 or 2


 Title   : stack_trace_dump
 Usage   :
 Example :
 Returns : 
 Args    :


 Title   : stack_trace
 Usage   : @stack_array_ref= $self->stack_trace
 Function: gives an array to a reference of arrays with stack trace info
           each coming from the caller(stack_number) call
 Returns : array containing a reference of arrays
 Args    : none


 Usage     : $object->_rearrange( array_ref, list_of_arguments)
 Purpose   : Rearranges named parameters to requested order.
 Example   : $self->_rearrange([qw(SEQUENCE ID DESC)],@param);
           : Where @param = (-sequence => $s, 
           :                 -id       => $i, 
           :                 -desc     => $d);
 Returns   : @params - an array of parameters in the requested order.
           : The above example would return ($s, $i, $d)
 Argument  : $order : a reference to an array which describes the desired
           :          order of the named parameters.
           : @param : an array of parameters, either as a list (in
           :          which case the function simply returns the list),
           :          or as an associative array with hyphenated tags
           :          (in which case the function sorts the values 
           :          according to @{$order} and returns that new array.)
           :          The tags can be upper, lower, or mixed case
           :          but they must start with a hyphen (at least the
           :          first one should be hyphenated.)
 Source    : This function was taken from CGI.pm, written by Dr. Lincoln
           : Stein, and adapted for use in Bio::Seq by Richard Resnick and
           : then adapted for use in Bio::Root::Object.pm by Steve Chervitz.
 Comments  : (SAC)
           : This method may not be appropriate for method calls that are
           : within in an inner loop if efficiency is a concern.
           : Parameters can be specified using any of these formats:
           :  @param = (-name=>'me', -color=>'blue');
           :  @param = (-NAME=>'me', -COLOR=>'blue');
           :  @param = (-Name=>'me', -Color=>'blue');
           :  @param = ('me', 'blue');
           : A leading hyphenated argument is used by this function to 
           : indicate that named parameters are being used.
           : Therefore, the ('me', 'blue') list will be returned as-is.
           : Note that Perl will confuse unquoted, hyphenated tags as 
           : function calls if there is a function of the same name 
           : in the current namespace:
           :    -name => 'foo' is interpreted as -&name => 'foo'
           : For ultimate safety, put single quotes around the tag:
           :    ('-name'=>'me', '-color' =>'blue');
           : This can be a bit cumbersome and I find not as readable
           : as using all uppercase, which is also fairly safe:
           :    (-NAME=>'me', -COLOR =>'blue');
           : Personal note (SAC): I have found all uppercase tags to
           : be more managable: it involves less single-quoting,
           : the code is more readable, and there are no method naming conlicts.
           : Regardless of the style, it greatly helps to line
           : the parameters up vertically for long/complex lists.


 Title   : _register_for_cleanup
 Usage   : -- internal --
 Function: Register a method to be called at DESTROY time. This is useful
           and sometimes essential in the case of multiple inheritance for
           classes coming second in the sequence of inheritance.
 Returns : 
 Args    : a code reference

The code reference will be invoked with the object as the first argument, as per a method. You may register an unlimited number of cleanup methods.


 Title   : _unregister_for_cleanup
 Usage   : -- internal --
 Function: Remove a method that has previously been registered to be called
           at DESTROY time.  If called with a methoda method to be called at DESTROY time.
           Has no effect if the code reference has not previously been registered.
 Returns : nothing
 Args    : a code reference


 Title   : _cleanup_methods
 Usage   : -- internal --
 Function: Return current list of registered cleanup methods.
 Returns : list of coderefs
 Args    : none


 Purpose : Throws a Bio::Root::NotImplemented exception.
           Intended for use in the method definitions of 
           abstract interface modules where methods are defined
           but are intended to be overridden by subclasses.
 Usage   : $object->throw_not_implemented();
 Example : sub method_foo { 
             $self = shift; 
 Returns : n/a
 Args    : n/a
 Throws  : A Bio::Root::NotImplemented exception.
           The message of the exception contains
             - the name of the method 
             - the name of the interface 
             - the name of the implementing class 

           If this object has a throw() method, $self->throw will be used.
           If the object doesn't have a throw() method, 
           Carp::confess() will be used.


 Purpose : Generates a warning that a method has not been implemented.
           Intended for use in the method definitions of 
           abstract interface modules where methods are defined
           but are intended to be overridden by subclasses.
           Generally, throw_not_implemented() should be used,
           but warn_not_implemented() may be used if the method isn't
           considered essential and convenient no-op behavior can be 
           provided within the interface.
 Usage   : $object->warn_not_implemented( method-name-string );
 Example : $self->warn_not_implemented( "get_foobar" );
 Returns : Calls $self->warn on this object, if available.
           If the object doesn't have a warn() method,
           Carp::carp() will be used.
 Args    : n/a