text:
- Class Declarations
- Field Declarations
- Object Creation
- Object Cloning
- Object Initialization
- Object Initialization Argument Specifications
- Getting Data
- Setting Data
- Automatic Accessor Generation
- Weak Fields
- Field Cloning
- Object ID
- Object Replication
- Object Destruction
- Cumulative Methods
- Chained Methods
- Automethods
- Object Serialization
- Dynamic Field Creation
- Restricted and Private Methods
- Hidden Methods
- Object Coercion
Object::InsideOut - Comprehensive inside-out object support module
This document describes Object::InsideOut version 1.44
package My::Class; {
use Object::InsideOut;
# Numeric field with combined get+set accessor
my @data :Field('Accessor' => 'data', 'Type' => 'NUMERIC');
# Takes 'DATA' (or 'data', etc.) as a manatory parameter to ->new()
my %init_args :InitArgs = (
'Regex' => qr/^data$/i,
'Mandatory' => 1,
'Type' => 'NUMERIC',
# Handle class-specific args as part of ->new()
sub init :Init
my ($self, $args) = @_;
$self->set(\@data, $args->{'DATA'});
package My::Class::Sub; {
use Object::InsideOut qw(My::Class);
# List field with standard 'get_X' and 'set_X' accessors
my @info :Field('Standard' => 'info', 'Type' => 'LIST');
# Takes 'INFO' as an optional list parameter to ->new()
# Value automatically added to @info array
# Defaults to [ 'empty' ]
my %init_args :InitArgs = (
'Type' => 'LIST',
'Field' => \@info,
'Default' => 'empty',
package main;
my $obj = My::Class::Sub->new('Data' => 69);
my $info = $obj->get_info(); # [ 'empty' ]
my $data = $obj->data(); # 69
$data = $obj->data(); # 42
$obj = My::Class::Sub->new('INFO' => 'help', 'DATA' => 86);
$data = $obj->data(); # 86
$info = $obj->get_info(); # [ 'help' ]
$obj->set_info(qw(foo bar baz));
$info = $obj->get_info(); # [ 'foo', 'bar', 'baz' ]
This module provides comprehensive support for implementing classes using the inside-out object model.
This module implements inside-out objects as anonymous scalar references that are blessed into a class with the scalar containing the ID for the object (usually a sequence number). For Perl 5.8.3 and later, the scalar reference is set as readonly to prevent accidental modifications to the ID. Object data (i.e., fields) are stored within the class's package in either arrays indexed by the object's ID, or hashes keyed to the object's ID.
The virtues of the inside-out object model over the blessed hash object model have been extolled in detail elsewhere. See the informational links under "SEE ALSO". Briefly, inside-out objects offer the following advantages over blessed hash objects:
Object data is enclosed within the class's code and is accessible only through the class-defined interface.
Field Name Collision Avoidance
Inheritance using blessed hash classes can lead to conflicts if any classes use the same name for a field (i.e., hash key). Inside-out objects are immune to this problem because object data is stored inside each class's package, and not in the object itself.
Compile-time Name Checking
A common error with blessed hash classes is the misspelling of field names:
$obj->{'coment'} = 'Say what?'; # Should be 'comment' not 'coment'
As there is no compile-time checking on hash keys, such errors do not usually manifest themselves until runtime.
With inside-out objects, text hash keys are not used for accessing field data. Field names and the data index (i.e., $$self) are checked by the Perl compiler such that any typos are easily caught using
perl -c.
$coment[$$self] = $value; # Causes a compile-time error # or with hash-based fields $comment{$$slef} = $value; # Also causes a compile-time error
This module offers all the capabilities of other inside-out object modules with the following additional key advantages:
When using arrays to store object data, Object::InsideOut objects are as much as 40% faster than blessed hash objects for fetching and setting data, and even with hashes they are still several percent faster than blessed hash objects.
Object::InsideOut is thread safe, and thoroughly supports sharing objects between threads using threads::shared.
Allows control over object ID specification, accessor naming, parameter name matching, and more.
Runtime Support
Supports classes that may be loaded at runtime (i.e., using
eval { require ...; };). This makes it usable from within mod_perl, as well. Also supports dynamic creation of object fields during runtime.
Perl 5.6 and 5.8
Tested on Perl v5.6.0 through v5.6.2, v5.8.0 through v5.8.8, and v5.9.3.
Exception Objects
As recommended in Perl Best Practices, Object::InsideOut uses Exception::Class for handling errors in an OO-compatible manner.
Object Serialization
Object::InsideOut has built-in support for object dumping and reloading that can be accomplished in either an automated fashion or through the use of class-supplied subroutines. Serialization using Storable is also supported.
Foreign Class Inheritance
Object::InsideOut allows classes to inherit from foreign (i.e., non-Object::InsideOut) classes, thus allowing you to sub-class other Perl class, and access their methods from your own objects.
Class Declarations
To use this module, your classes will start with
use Object::InsideOut;:
package My::Class; {
use Object::InsideOut;
Sub-classes inherit from base classes by telling Object::InsideOut what the parent class is:
package My::Sub; {
use Object::InsideOut qw(My::Parent);
Multiple inheritance is also supported:
package My::Project; {
use Object::InsideOut qw(My::Class Another::Class);
Object::InsideOut acts as a replacement for the
base pragma: It loads the parent module(s), calls their
import functions, and sets up the sub-class's @ISA array. Therefore, you should not
use base ... yourself, or try to set up
@ISA arrays.
If a parent class takes parameters (e.g., symbols to be exported via Exporter), enclose them in an array ref (mandatory) following the name of the parent class:
package My::Project; {
use Object::InsideOut 'My::Class' => [ 'param1', 'param2' ],
'Another::Class' => [ 'param' ];
Field Declarations
Object data fields consist of arrays within a class's package into which data are stored using the object's ID as the array index. An array is declared as being an object field by following its declaration with the
:Field attribute:
my @info :Field;
Object data fields may also be hashes:
my %data :Field;
However, as array access is as much as 40% faster than hash access, you should stick to using arrays. (See "Object ID" concerning when hashes may be required.)
(The case of the word Field does not matter, but by convention should not be all lowercase.)
Object Creation
Objects are created using the
->new() method which is exported by Object::InsideOut to each class:
my $obj = My::Class->new();
Classes do not (normally) implement their own
->new() method. Class-specific object initialization actions are handled by
:Init labeled methods (see "Object Initialization").
Parameters are passed in as combinations of
key => value pairs and/or hash refs:
my $obj = My::Class->new('param1' => 'value1');
# or
my $obj = My::Class->new({'param1' => 'value1'});
# or even
my $obj = My::Class->new(
'param_X' => 'value_X',
'param_Y' => 'value_Y',
'param_A' => 'value_A',
'param_B' => 'value_B',
'param_Q' => 'value_Q',
Additionally, parameters can be segregated in hash refs for specific classes:
my $obj = My::Class->new(
'foo' => 'bar',
'My::Class' => { 'param' => 'value' },
'Parent::Class' => { 'data' => 'info' },
The initialization methods for both classes in the above will get
'foo' => 'bar',
My::Class will also get
'param' => 'value', and
Parent::Class will also get
'data' => 'info'. In this scheme, class-specific parameters will override general parameters specified at a higher level:
my $obj = My::Class->new(
'default' => 'bar',
'Parent::Class' => { 'default' => 'baz' },
My::Class will get
'default' => 'bar', and
Parent::Class will get
'default' => 'baz'.
new on an object works, too, and operates the same as calling
new for the class of the object (i.e.,
$obj->new() is the same as
NOTE: You cannot create objects from Object::InsideOut itself:
# This is an error
# my $obj = Object::InsideOut->new();
In this way, Object::InsideOut is not an object class, but functions more like a pragma.
Object Cloning
Copies of objects can be created using the
->clone() method which is exported by Object::InsideOut to each class:
my $obj2 = $obj->clone();
When called without arguments,
->clone() creates a shallow copy of the object, meaning that any complex data structures (i.e., array, hash or scalar refs) stored in the object will be shared with its clone.
->clone() with a true argument:
my $obj2 = $obj->clone(1);
creates a deep copy of the object such that internally held array, hash or scalar refs are replicated and stored in the newly created clone.
Deep cloning can also be controlled at the field level. See "Field Cloning" below for more details.
Note that cloning does not clone internally held objects. For example, if
$foo contains a reference to
$bar, a clone of
$foo will also contain a reference to
$bar; not a clone of
$bar. If such behavior is needed, it must be provided using a :Replicate subroutine.
Object Initialization
Object initialization is accomplished through a combination of an
:InitArgs labeled hash (explained in detail in the next section), and an
:Init labeled subroutine.
:InitArgs labeled hash specifies the parameters to be extracted from the argument list supplied to the
->new() method. These parameters are then sent to the
:Init labeled subroutine for processing:
package My::Class; {
my @my_field :Field;
my %init_args :InitArgs = (
'MY_PARAM' => qr/MY_PARAM/i,
sub _init :Init
my ($self, $args) = @_;
if (exists($args->{'MY_PARAM'})) {
$self->set(\@my_field, $args->{'MY_PARAM'});
package main;
my $obj = My::Class->new('my_param' => 'data');
(The case of the words InitArgs and Init does not matter, but by convention should not be all lowercase.)
:Init labeled subroutine will receive two arguments: The newly created object requiring further initialization (i.e.,
$self), and a hash ref of supplied arguments that matched
:InitArgs specifications.
Data processed by the subroutine may be placed directly into the class's field arrays (hashes) using the object's ID (i.e.,
$my_field[$$self] = $args->{'MY_PARAM'};
However, it is strongly recommended that you use the ->set() method:
$self->set(\@my_field, $args->{'MY_PARAM'});
which handles converting the data to a shared format when needed for applications using threads::shared.
Object Initialization Argument Specifications
The parameters to be handled by the
->new() method are specified in a hash that is labeled with the
:InitArgs attribute.
The simplest parameter specification is just a tag:
my %init_args :InitArgs = (
In this case, if a
key => value pair with an exact match of
DATA for the key is found in the arguments sent to the
->new() method, then
'DATA' => value will be included in the argument hash ref sent to the
:Init labeled subroutine.
- Parameter Name Matching
Rather than counting on exact matches, regular expressions can be used to specify the parameter:
my %init_args :InitArgs = ( 'Param' => qr/^PARA?M$/i, );
In this case, the argument key could be any of the following: PARAM, PARM, Param, Parm, param, parm, and so on. If a match is found, then
'Param' => valueis sent to the
:Initsubroutine. Note that the
:InitArgshash key is substituted for the original argument key. This eliminates the need for any parameter key pattern matching within the
If additional parameter specifications (described below) are used, the syntax changes, and the regular expression is moved inside a hash ref:
my %init_args :InitArgs = ( 'Param' => { 'Regex' => qr/^PARA?M$/i, }, );
- Mandatory Parameters
Mandatory parameters are declared as follows:
my %init_args :InitArgs = ( # Mandatory parameter requiring exact matching 'INFO' => { 'Mandatory' => 1, }, # Mandatory parameter with pattern matching 'input' => { 'Regex' => qr/^in(?:put)?$/i, 'Mandatory' => 1, }, );
If a mandatory parameter is missing from the argument list to
new, an error is generated.
- Default Values
For optional parameters, defaults can be specified:
my %init_args :InitArgs = ( 'LEVEL' => { 'Regex' => qr/^lev(?:el)?|lvl$/i, 'Default' => 3, }, );
- Type Checking
The parameter's type can also be specified:
my %init_args :InitArgs = ( 'LEVEL' => { 'Regex' => qr/^lev(?:el)?|lvl$/i, 'Default' => 3, 'Type' => 'Numeric', }, );
Available types are:
- Numeric
Can also be specified as
Number. This uses Scalar::Util::looks_like_number to test the input value.
- List
This type permits a single value (that is then placed in an array ref) or an array ref.
- A class name
The parameter's type must be of the specified class, or one of its sub-classes (i.e., type checking is done using
->isa()). For example,
- Other reference type
The parameter's type must be of the specified reference type (as returned by ref()). For example,
The first two types above are case-insensitive (e.g., 'NUMERIC', 'Numeric', 'numeric', etc.); the last two are case-sensitive.
Typekeyword may also be paired with a code reference to provide custom type checking. The code ref can either be in the form of an anonymous subroutine, or it can be derived from a (publicly accessible) subroutine. The result of executing the code ref on the initializer should be a boolean value.
package My::Class; { use Object::InsideOut; # For initializer type checking, the subroutine can NOT be made 'Private' sub is_int { my $arg = $_[0]; return (Scalar::Util::looks_like_number($arg) && (int($arg) == $arg)); } my @level :Field; my @comment :Field; my %init_args :InitArgs = ( 'LEVEL' => { 'Field' => \@level, # Type checking using a named subroutine 'Type' => \&is_int, }, 'COMMENT' => { 'Field' => \@comment, # Type checking using an anonymous subroutine 'Type' => sub { $_[0] ne '' } }, ); }
- Automatic Processing
You can specify automatic processing for a parameter's value such that it is placed directly into a field array/hash, and not sent to the
my @hosts :Field; my %init_args :InitArgs = ( 'HOSTS' => { # Allow 'host' or 'hosts' - case-insensitive 'Regex' => qr/^hosts?$/i, # Mandatory parameter 'Mandatory' => 1, # Allow single value or array ref 'Type' => 'List', # Automatically put the parameter into @hosts 'Field' => \@hosts, }, );
In this case, when the host parameter is found, it is automatically put into the
@hostsarray, and a
'HOSTS' => valuepair is not sent to the
:Initsubroutine. In fact, if you specify fields for all your parameters, then you don't even need to have an
:Initsubroutine! All the work will be taken care of for you.
- Parameter Preprocessing
You can specify a subroutine for a parameter that will be called on that parameter prior to any of the other parameter actions described above being taken:
package My::Class; { use Object::InsideOut; my @data :Field; my %init_args :InitArgs = ( 'DATA' => { 'Preprocess' => \&my_preproc, 'Field' => \@data, 'Type' => 'Numeric', 'Default' => 99, }, ); sub my_preproc { my ($class, $param, $spec, $obj, $value) = @_; # Preform parameter preprocessing ... # Return result return ...; } }
As the above illustrates, the parameter preprocessing subroutine is sent five arguments:
The name of the class associated with the parameter
This would be
My::Classin the example above.
The name of the parameter
This would be
DATAin the example above.
A hash ref of the parameter's specifiers
The hash ref paired to the
DATAkey in the
The object being initialized
The parameter's value
This is the value assigned to the parameter in the
->new()method's argument list. If the parameter was not provided to
->new(), then
undefwill sent.
The return value of the preprocessing subroutine will then be assigned to the parameter.
Be careful about what types of data the preprocessing subroutine tries to make use of
externalto the arguments supplied. For instance, because the order of parameter processing is not specified, the preprocessing subroutine cannot rely on whether or not some other parameter is set. Such processing would need to be done in the
:Initsubroutine. It can, however, make use of object data set by classes higher up in the class hierarchy. (That is why the object is provided as one of the arguments.)
Possible uses for parameter preprocessing include:
Overriding the supplied value (or even deleting it by returning
Providing a dynamically-determined default value
(In the above, Regex may be Regexp or just Re, Default may be Defaults or Def, and Preprocess may be Preproc or Pre. They and the other specifier keys are case-insensitive, as well.)
Getting Data
In class code, data can be fetched directly from an object's field array (hash) using the object's ID:
$data = $field[$$self];
# or
$data = $field{$$self};
Setting Data
Object::InsideOut automatically exports a method called
set to each class. This method should be used in class code to put data into object field arrays/hashes whenever there is the possibility that the class code may be used in an application that uses threads::shared.
As mentioned above, data can be put directly into an object's field array (hash) using the object's ID:
$field[$$self] = $data;
# or
$field{$$self} = $data;
However, in a threaded application that uses data sharing (i.e., uses
$data must be converted into shared data so that it can be put into the field array (hash). The
->set() method handles all those details for you.
->set() method, requires two arguments: A reference to the object field array/hash, and the data (as a scalar) to be put in it:
$self->set(\@field, $data);
# or
$self->set(\%field, $data);
To be clear, the
->set() method is used inside class code; not application code. Use it inside any object methods that set data in object field arrays/hashes.
In the event of a method naming conflict, the
->set() method can be called using its fully-qualified name:
$self->Object::InsideOut::set(\@field, $data);
Automatic Accessor Generation
As part of the "Field Declarations", you can optionally specify the automatic generation of accessor methods.
- Accessor Naming
You can specify the generation of a pair of standard-named accessor methods (i.e., prefixed by get_ and set_):
my @data :Field('Standard' => 'data');
The above results in Object::InsideOut automatically generating accessor methods named
set_data. (The keyword
Standardis case-insensitive, and can be abbreviated to
You can also separately specify the get and/or set accessors:
my @name :Field('Get' => 'name', 'Set' => 'change_name'); # or my @name :Field('Get' => 'get_name'); # or my @name :Field('Set' => 'new_name');
For the above, you specify the full name of the accessor(s) (i.e., no prefix is added to the given name(s)). (The
Setkeywords are case-insensitive.)
You can specify the automatic generation of a combined get/set accessor method:
my @comment :Field('Accessor' => 'comment');
which would be used as follows:
# Set a new comment $obj->comment("I have no comment, today."); # Get the current comment my $cmt = $obj->comment();
(The keyword
Accessoris case-insensitive, and can be abbreviated to
Accor can be specified as
- Set Accessor Return Value
For any of the automatically generated methods that perform set operations, the default for the method's return value is the value being set (i.e., the new value).
Returnkeyword allows you to modify the default behavior. The other options are to have the set accessor return the old (previous) value (or
undefif unset):
my @data :Field('Set' => 'set_data', 'Return' => 'Old');
or to return the object itself:
my @data :Field('Set' => 'set_data', 'Return' => 'Object');
Returning the object from a set method allows it to be chained to other methods:
If desired, you can explicitly specify the default behavior of returning the new value:
my @data :Field('Set' => 'set_data', 'Return' => 'New');
Returnmay be abbreviated to
Priorare synonymous with
Old; and
Objectmay be abbreviated to
Objand is also synonymous with
Self. All these are case-insensitive.)
- Accessor Type Checking
You may, optionally, direct Object::InsideOut to add type-checking code to the set/combined accessor:
my @level :Field('Accessor' => 'level', 'Type' => 'Numeric');
Available types are:
- Numeric
Can also be specified as
Number. This uses Scalar::Util::looks_like_number to test the input value.
- List or Array
This type permits the accessor to accept multiple values (that are then placed in an array ref) or a single array ref.
- Array_ref
This specifies that the accessor can only accept a single array reference. Can also be specified as
- Hash
This type allows multiple
key => valuepairs (that are then placed in a hash ref) or a single hash ref.
- Hash_ref
This specifies that the accessor can only accept a single hash reference. Can also be specified as
- A class name
The accessor will only accept a value of the specified class, or one of its sub-classes (i.e., type checking is done using
->isa()). For example,
- Other reference type
The accessor will only accept a value of the specified reference type (as returned by ref()). For example,
The types above are case-insensitive (e.g., 'NUMERIC', 'Numeric', 'numeric', etc.), except for the last two.
Typekeyword can also be paired with a code reference to provide custom type checking. The code ref can either be in the form of an anonymous subroutine, or a fully-qualified subroutine name. The result of executing the code ref on the input argument should be a boolean value.
package My::Class; { use Object::InsideOut; # For accessor type checking, the subroutine can be made 'Private' sub positive :Private { return (Scalar::Util::looks_like_number($_[0]) && ($_[0] > 0)); } # Code ref is an anonymous subroutine # (This one checks that the argument is a SCALAR) my @data :Field('Accessor' => 'data', 'Type' => sub { ! ref($_[0]) } ); # Code ref using a fully-qualified subroutine name my @num :Field('Accessor' => 'num', 'Type' => \&My::Class::positive); }
Note that it is an error to use the
Typekeyword by itself, or in combination with only the
Due to limitations in the Perl parser, you cannot use line wrapping with the
# This doesn't work # my @level :Field('Get' => 'level', # 'Set' => 'set_level', # 'Type' => 'Num'); # Must be all on one line my @level :Field('Get' =>'level', 'Set' => 'set_level', 'Type' => 'Num');
Weak Fields
Frequently, it is useful to store weakened references to data or objects in a field. Such a field can be declared as
weak so that data (i.e., references) set via automatically generated accessors,
:InitArgs, the
->set() method, etc., will automatically be weakened after being stored in the field array/hash.
my @data :Field('Weak' => 1);
NOTE: If data in a weak field is set directly (i.e., the
->set() method is not used), then weaken() must be invoked on the stored reference afterwards:
$field[$$self] = $data;
Field Cloning
Object cloning can be controlled at the field level such that only specified fields are deep copied when
->clone() is called without any arguments. This is done by adding another specifier to the
:Field attribute:
my @data :Field('Clone' => 'deep');
# or
my @data :Field('Copy' => 'deep');
# or
my @data :Field('Deep' => 1);
As usual, the keywords above are case-insensitive.
Object ID
By default, the ID of an object is derived from a sequence counter for the object's class hierarchy. This should suffice for nearly all cases of class development. If there is a special need for the module code to control the object ID (see Math::Random::MT::Auto as an example), then an
:ID labeled subroutine can be specified:
sub _id :ID
my $class = $_[0];
# Determine a unique object ID
return ($id);
The ID returned by your subroutine can be any kind of regular scalar (e.g., a string or a number). However, if the ID is something other than a low-valued integer, then you will have to architect all your classes using hashes for the object fields.
Within any class hierarchy only one class may specify an
:ID subroutine.
Object Replication
Object replication occurs explicitly when the
->clone() method is called on an object, and implicitly when threads are created in a threaded application. In nearly all cases, Object::InsideOut will take care of all the details for you.
In rare cases, a class may require special handling for object replication. It must then provide a subroutine labeled with the
:Replicate attribute. This subroutine will be sent three arguments: The parent and the cloned objects, and a flag:
sub _replicate :Replicate
my ($parent, $clone, $flag) = @_;
# Special object replication processing
if ($clone eq 'CLONE') {
# Handling for thread cloning
} elsif ($clone eq 'deep') {
# Deep copy of the parent
} else {
# Shallow copying
In the case of thread cloning,
$flag will be set to
'CLONE', and the
$parent object is just an un-blessed anonymous scalar reference that contains the ID for the object in the parent thread.
When invoked via the
->clone() method,
$flag may be either an empty string which denotes that a shallow copy is being produced for the clone, or
$flag may be set to
'deep' indicating a deep copy is being produced.
:Replicate subroutine only needs to deal with the special replication processing needed by the object: Object::InsideOut will handle all the other details.
Object Destruction
Object::InsideOut exports a
DESTROY method to each class that deletes an object's data from the object field arrays (hashes). If a class requires additional destruction processing (e.g., closing filehandles), then it must provide a subroutine labeled with the
:Destroy attribute. This subroutine will be sent the object that is being destroyed:
sub _destroy :Destroy
my $obj = $_[0];
# Special object destruction processing
:Destroy subroutine only needs to deal with the special destruction processing: The
DESTROY method will handle all the other details of object destruction.
Cumulative Methods
Normally, methods with the same name in a class hierarchy are masked (i.e., overridden) by inheritance - only the method in the most-derived class is called. With cumulative methods, this masking is removed, and the same named method is called in each of the classes within the hierarchy. The return results from each call (if any) are then gathered together into the return value for the original method call. For example,
package My::Class; {
use Object::InsideOut;
sub what_am_i :Cumulative
my $self = shift;
my $ima = (ref($self) eq __PACKAGE__)
? q/I was created as a /
: q/My top class is /;
return ($ima . __PACKAGE__);
package My::Foo; {
use Object::InsideOut 'My::Class';
sub what_am_i :Cumulative
my $self = shift;
my $ima = (ref($self) eq __PACKAGE__)
? q/I was created as a /
: q/I'm also a /;
return ($ima . __PACKAGE__);
package My::Child; {
use Object::InsideOut 'My::Foo';
sub what_am_i :Cumulative
my $self = shift;
my $ima = (ref($self) eq __PACKAGE__)
? q/I was created as a /
: q/I'm in class /;
return ($ima . __PACKAGE__);
package main;
my $obj = My::Child->new();
my @desc = $obj->what_am_i();
print(join("\n", @desc), "\n");
My top class is My::Class
I'm also a My::Foo
I was created as a My::Child
When called in a list context (as in the above), the return results of cumulative methods are accumulated, and returned as a list.
In a scalar context, a results object is returned that segregates the results from the cumulative method calls by class. Through overloading, this object can then be dereferenced as an array, hash, string, number, or boolean. For example, the above could be rewritten as:
my $obj = My::Child->new();
my $desc = $obj->what_am_i(); # Results object
print(join("\n", @{$desc}), "\n"); # Dereference as an array
The following uses hash dereferencing:
my $obj = My::Child->new();
my $desc = $obj->what_am_i();
while (my ($class, $value) = each(%{$desc})) {
print("Class $class reports:\n\t$value\n");
and produces:
Class My::Class reports:
My top class is My::Class
Class My::Child reports:
I was created as a My::Child
Class My::Foo reports:
I'm also a My::Foo
As illustrated above, Cumulative methods are tagged with the
:Cumulative attribute (or
:Cumulative(top down)), and propagate from the top down through the class hierarchy (i.e., from the base classes down through the child classes). If tagged with
:Cumulative(bottom up), they will propagated from the object's class upwards through the parent classes.
Chained Methods
In addition to
:Cumulative, Object::InsideOut provides a way of creating methods that are chained together so that their return values are passed as input arguments to other similarly named methods in the same class hierarchy. In this way, the chained methods act as though they were piped together.
For example, imagine you had a method called
format_name that formats some text for display:
package Subscriber; {
use Object::InsideOut;
sub format_name {
my ($self, $name) = @_;
# Strip leading and trailing whitespace
$name =~ s/^\s+//;
$name =~ s/\s+$//;
return ($name);
And elsewhere you have a second class that formats the case of names:
package Person; {
use Lingua::EN::NameCase qw(nc);
use Object::InsideOut;
sub format_name {
my ($self, $name) = @_;
# Attempt to properly case names
return (nc($name));
And you decide that you'd like to perform some formatting of your own, and then have all the parent methods apply their own formatting. Normally, if you have a single parent class, you'd just call the method directly with
$self-SUPER::format_name($name)>, but if you have more than one parent class you'd have to explicitly call each method directly:
package Customer; {
use Object::InsideOut qw(Person Subscriber);
sub format_name {
my ($self, $name) = @_;
# Compress all whitespace into a single space
$name =~ s/\s+/ /g;
$name = $self->Subscriber::format_name($name);
$name = $self->Person::format_name($name);
return $name;
With Object::InsideOut you'd add the
:Chained attribute to each class's
format_name method, and the methods will be chained together automatically:
package Subscriber; {
use Object::InsideOut;
sub format_name :Chained {
my ($self, $name) = @_;
# Strip leading and trailing whitespace
$name =~ s/^\s+//;
$name =~ s/\s+$//;
return ($name);
package Person; {
use Lingua::EN::NameCase qw(nc);
use Object::InsideOut;
sub format_name :Chained {
my ($self, $name) = @_;
# Attempt to properly case names
return (nc($name));
package Customer; {
use Object::InsideOut qw(Person Subscriber);
sub format_name :Chained {
my ($self, $name) = @_;
# Compress all whitespace into a single space
$name =~ s/\s+/ /g;
return ($name);
So passing in someone's name to
format_name in
Customer would cause leading and trailing whitespace to be removed, then the name to be properly cased, and finally whitespace to be compressed to a single space. The resulting
$name would be returned to the caller.
The default direction is to chain methods from the base classes at the top of the class hierarchy down through the child classes. You may use the attribute
:Chained(top down) to make this more explicit.
If you label the method with the
:Chained(bottom up) attribute, then the chained methods are called starting with the object's class and working upwards through the class hierarchy, similar to how
:Cumulative(bottom up) works.
:Cumulative methods,
:Chained methods return a scalar when used in a scalar context; not a results object.
There are significant issues related to Perl's
AUTOLOAD mechanism that cause it to be ill-suited for use in a class hierarchy. Therefore, Object::InsideOut implements its own
:Automethod mechanism to overcome these problems.
Classes requiring
AUTOLOAD-type capabilities must provided a subroutine labeled with the
:Automethod attribute. The
:Automethod subroutine will be called with the object and the arguments in the original method call (the same as for
AUTOLOAD). The
:Automethod subroutine should return either a subroutine reference that implements the requested method's functionality, or else
undef to indicate that it doesn't know how to handle the request.
Using its own
AUTOLOAD subroutine (which is exported to every class), Object::InsideOut walks through the class tree, calling each
:Automethod subroutine, as needed, to fulfill an unimplemented method call.
The name of the method being called is passed as
$_ instead of
$AUTOLOAD, and does not have the class name prepended to it. If the
:Automethod subroutine also needs to access the
$_ from the caller's scope, it is available as
Automethods can also be made to act as "Cumulative Methods" or "Chained Methods". In these cases, the
:Automethod subroutine should return two values: The subroutine ref to handle the method call, and a string designating the type of method. The designator has the same form as the attributes used to designate
:Cumulative and
:Chained methods:
':Cumulative' or ':Cumulative(top down)'
':Cumulative(bottom up)'
':Chained' or ':Chained(top down)'
':Chained(bottom up)'
The following skeletal code illustrates how an
:Automethod subroutine could be structured:
sub _automethod :Automethod
my $self = shift;
my @args = @_;
my $method_name = $_;
# This class can handle the method directly
if (...) {
my $handler = sub {
my $self = shift;
return ...;
# Install the handler so it gets called directly next time
# no strict refs;
# *{__PACKAGE__.'::'.$method_name} = $handler;
return ($handler);
# This class can handle the method as part of a chain
if (...) {
my $chained_handler = sub {
my $self = shift;
return ...;
return ($chained_handler, ':Chained');
# This class cannot handle the method request
Note: The OPTIONAL code above for installing the generated handler as a method should not be used with
:Cumulative or
:Chained Automethods.
Object Serialization
- my $array_ref = $obj->dump();
- my $string = $obj->dump(1);
Object::InsideOut exports a method called
dumpto each class that returns either a Perl or a string representation of the object that invokes the method.
The Perl representation is returned when
->dump()is called without arguments. It consists of an array ref whose first element is the name of the object's class, and whose second element is a hash ref containing the object's data. The object data hash ref contains keys for each of the classes that make up the object's hierarchy. The values for those keys are hash refs containing
key => valuepairs for the object's fields. For example:
[ 'My::Class::Sub', { 'My::Class' => { 'data' => 'value' }, 'My::Class::Sub' => { 'life' => 42 } } ]
The name for an object field (data and life in the example above) can be specified as part of the field declaration using the
my @life :Field('Name' => 'life');
If the
NAMEkeyword is not present, then the name for a field will be either the tag from the
:InitArgsarray that is associated with the field, its get method name, its set method name, or, failing all that, a string of the form
When called with a true argument,
->dump()returns a string version of the Perl representation using Data::Dumper.
Note that using Data::Dumper directly on an inside-out object will not produce the desired results (it'll just output the contents of the scalar ref). Also, if inside-out objects are stored inside other structures, a dump of those structures will not contain the contents of the object's fields.
In the event of a method naming conflict, the
->dump()method can be called using its fully-qualified name:
my $dump = $obj->Object::InsideOut::dump();
- my $obj = Object::InsideOut->pump($data);
Object::InsideOut->pump()takes the output from the
->dump()method, and returns an object that is created using that data. If
$datais the array ref returned by using
$obj->dump(), then the data is inserted directly into the corresponding fields for each class in the object's class hierarchy. If
$datais the string returned by using
$obj->dump(1), then it is
evaled to turn it into an array ref, and then processed as above.
If any of an object's fields are dumped to field name keys of the form
HASH(0x...)(see above), then the data will not be reloadable using
Object::InsideOut->pump(). To overcome this problem, the class developer must either add
Namekeywords to the
:Fielddeclarations (see above), or provide a
:Pumperpair of subroutines as described below.
:DumperSubroutine Attribute
If a class requires special processing to dump its data, then it can provide a subroutine labeled with the
:Dumperattribute. This subroutine will be sent the object that is being dumped. It may then return any type of scalar the developer deems appropriate. Most likely this would be a hash ref containing
key => valuepairs for the object's fields. For example,
my @data :Field; sub _dump :Dumper { my $obj = $_[0]; my %field_data; $field_data{'data'} = $data[$$obj]; return (\%field_data); }
Just be sure not to call your
dumpas that is the name of the dump method exported by Object::InsideOut as explained above.
:PumperSubroutine Attribute
If a class supplies a
:Dumpersubroutine, it will most likely need to provide a complementary
:Pumperlabeled subroutine that will be used as part of creating an object from dumped data using
Object::InsideOut::pump(). The subroutine will be supplied the new object that is being created, and whatever scalar was returned by the
:Dumpersubroutine. The corresponding
:Pumperfor the example
:Dumperabove would be:
sub _pump :Pumper { my ($obj, $field_data) = @_; $data[$$obj] = $field_data->{'data'}; }
- Storable
Object::InsideOut also supports object serialization using the Storable module. There are two methods for specifying that a class can be serialized using Storable. The first method involves adding Storable to the Object::InsideOut declaration in your package:
package My::Class; { use Object::InsideOut qw(Storable); ... }
and adding
use Storable;in your application. Then you can use the
->freeze()methods to serialize your objects, and the
thaw()subroutines to deserialize them.
package main; use Storable; use My::Class; my $obj = My::Class->new(...); $obj->store('/tmp/object.dat'); ... my $obj2 = retrieve('/tmp/object.dat');
The other method of specifying Storable serialization involves setting a
::storablevariable (inside a
BEGINblock) for the class prior to its use:
package main; use Storable; BEGIN { $My::Class::storable = 1; } use My::Class;
Dynamic Field Creation
Normally, object fields are declared as part of the class code. However, some classes may need the capability to create object fields on-the-fly, for example, as part of an
:Automethod. Object::InsideOut provides a class method for this:
# Dynamically create a hash field with standard accessors
Object::InsideOut->create_field($class, '%'.$fld, "'Standard'=>'$fld'");
The first argument is the class to which the field will be added. The second argument is a string containing the name of the field preceeded by either a
@ or
% to declare an array field or hash field, respectively. The third argument is a string containing
key => value pairs used in conjunction with the
:Field attribute for generating field accessors.
Here's a more elaborate example used in inside an
package My::Class; {
use Object::InsideOut;
sub auto :Automethod
my $self = $_[0];
my $class = ref($self) || $self;
my $method = $_;
# Extract desired field name from get_/set_ method name
my ($fld_name) = $method =~ /^[gs]et_(.*)$/;
if (! $fld_name) {
return; # Not a recognized method
# Create the field and its standard accessors
Object::InsideOut->create_field($class, '@'.$fld_name,
# Return code ref for newly created accessor
no strict 'refs';
return *{$class.'::'.$method}{'CODE'};
Restricted and Private Methods
Access to certain methods can be narrowed by use of the
:Restricted and
:Private attributes.
:Restricted methods can only be called from within the class's hierarchy.
:Private methods can only be called from within the method's class.
Without the above attributes, most methods have public access. If desired, you may explicitly label them with the
:Public attribute.
You can also specify access permissions on automatically generated accessors:
my @data :Field('Standard' => 'data', 'Permission' => 'private');
my @info :Field('Set' => 'set_info', 'Perm' => 'restricted');
my @internal :Field('Acc' => 'internal', 'Private' => 1);
my @state :Field('Get' => 'state', 'Restricted' => 1);
Such permissions apply to both of the get and set accessors created on a field. If different permissions are required on an accessor pair, then you'll have to create the accessors yourself, using the
:Restricted and
:Private attributes when applicable:
# Create a private set method on the 'foo' field
my @foo :Field('Set' => 'set_foo', 'Priv' => 1);
# Read access on the 'foo' field is restricted
sub get_foo :Restrict
return ($foo[${$_[0]}]);
# Create a restricted set method on the 'bar' field
my %bar :Field('Set' => 'set_bar', 'Perm' => 'restrict');
# Read access on the 'foo' field is public
sub get_bar
return ($bar{${$_[0]}});
Hidden Methods
For subroutines marked with the following attributes:
Object::InsideOut normally renders them uncallable (hidden) to class and application code (as they should normally only be needed by Object::InsideOut itself). If needed, this behavior can be overridden by adding the
RESTRICTED or
PRIVATE keywords following the attribute:
sub _init :Init(private) # Callable from within this class
my ($self, $args) = @_;
NOTE: A bug in Perl 5.6.0 prevents using these access keywords. As such, subroutines marked with the above attributes will be left with public access.
NOTE: The above cannot be accomplished by using the corresponding attributes. For example:
# sub _init :Init :Private # Wrong syntax - doesn't work
Object Coercion
Object::InsideOut provides support for various forms of object coercion through the overload mechanism. For instance, if you want an object to be usable directly in a string, you would supply a subroutine in your class labeled with the
:Stringify attribute:
sub as_string :Stringify
my $self = $_[0];
my $string = ...;
return ($string);
Then you could do things like:
print("The object says, '$obj'\n");
For a boolean context, you would supply:
sub as_string :Boolify
my $self = $_[0];
my $true_or_false = ...;
return ($true_or_false);
and use it in this manner:
if (! defined($obj)) {
# The object is undefined
} elsif (! $obj) {
# The object returned a false value
The following coercion attributes are supported:
Coercing an object to a scalar (
:Scalarify) is not supported as
$$obj is the ID of the object and cannot be overridden.
Object::InsideOut supports inheritance from foreign (i.e., non-Object::InsideOut) classes. This means that your classes can inherit from other Perl class, and access their methods from your own objects.
One method of declaring foreign class inheritance is to add the class name to the Object::InsideOut declaration inside your package:
package My::Class; {
use Object::InsideOut qw(Foreign::Class);
This allows you to access the foreign class's static (i.e., class) methods from your own class. For example, suppose
Foreign::Class has a class method called
foo. With the above, you can access that method using
My::Class->foo() instead.
Multiple foreign inheritance is supported, as well:
package My::Class; {
use Object::InsideOut qw(Foreign::Class Other::Foreign::Class);
- $self->inherit($obj, ...);
To use object methods from foreign classes, an object must inherit from an object of that class. This would normally be done inside a class's
package My::Class; { use Object::InsideOut qw(Foreign::Class); sub init :Init { my ($self, $args) = @_; my $foreign_obj = Foreign::Class->new(...); $self->inherit($foreign_obj); } }
Thus, with the above, if
Foreign::Classhas an object method called
bar, you can call that method from your own objects:
package main; my $obj = My::Class->new(); $obj->bar();
AUTOLOADsubroutine handles the dispatching of the
->bar()method call using the internally held inherited object (in this case,
Multiple inheritance is supported, as well: You can call the
->inherit()method multiple times, or make just one call with all the objects to be inherited from.
->inherit()is a restricted method. In other words, you cannot use it on an object outside of code belonging to the object's class tree (e.g., you can't call it from application code).
In the event of a method naming conflict, the
->inherit()method can be called using its fully-qualified name:
- my @objs = $self->heritage();
- my $obj = $self->heritage($class);
- my @objs = $self->heritage($class1, $class2, ...);
Your class code can retrieve any inherited objects using the
->heritage()method. When called without any arguments, it returns a list of any objects that were stored by the calling class using the calling object. In other words, if class
My::Classuses object
$objto store foreign objects
$fobj2, then later on in class
$obj->heritage()will return
->heritage()can also be called with one or more class name arguments. In this case, only objects of the specified class(es) are returned.
In the event of a method naming conflict, the
->heritage()method can be called using its fully-qualified name:
my @objs = $self->Object::InsideOut::heritage();
- $self->disinherit($class [, ...])
- $self->disinherit($obj [, ...])
->disinherit()method disassociates (i.e., deletes) the inheritance of foreign object(s) from an object. The foreign objects may be specified by class, or using the actual inherited object (retrieved via
->heritage(), for example).
The call is only effective when called inside the class code that established the initial inheritance. In other words, if an inheritance is set up inside a class, then disinheritance can only be done from inside that class.
In the event of a method naming conflict, the
->disinherit()method can be called using its fully-qualified name:
$self->Object::InsideOut::disinherit($obj [, ...])
NOTE: With foreign inheritance, you only have access to class and object methods. The encapsulation of the inherited objects is strong, meaning that only the class where the inheritance takes place has direct access to the inherited object. If access to the inherited objects themselves, or their internal hash fields (in the case of blessed hash objects), is needed outside the class, then you'll need to write your own accessors for that.
LIMITATION: You cannot use fully-qualified method names to access foreign methods (when encapsulated foreign objects are involved). Thus, the following will not work:
my $obj = My::Class->new();
Normally, you shouldn't ever need to do the above:
$obj->bar() would suffice.
The only time this may be an issue is when the native class overrides an inherited foreign class's method (e.g.,
My::Class has its own
->bar() method). Such overridden methods are not directly callable. If such overriding is intentional, then this should not be an issue: No one should be writing code that tries to by-pass the override. However, if the overriding is accidently, then either the native method should be renamed, or the native class should provide a wrapper method so that the functionality of the overridden method is made available under a different name.
use base and Fully-qualified Method Names
The foreign inheritance methodology handled by the above is predicated on non-Object::InsideOut classes that generate their own objects and expect their object methods to be invoked via those objects.
There are exceptions to this rule:
- 1. Foreign object methods that expect to be invoked via the inheriting class's object, or foreign object methods that don't care how they are invoked (i.e., they don't make reference to the invoking object).
This is the case where a class provides auxiliary methods for your objects, but from which you don't actually create any objects (i.e., there is no corresponding foreign object, and
$obj->inherit($foreign)is not used.)
In this case, you can either:
a. Declare the foreign class using the standard method (i.e.,
use Object::InsideOut qw(Foreign::Class);), and invoke its methods using their full path (e.g.,
$obj->Foreign::Class::method();); or
b. You can use the base pragma so that you don't have to use the full path for foreign methods.
package My::Class; { use Object::InsideOut; use base 'Foreign::Class'; ... }
The former scheme is faster.
- 2. Foreign class methods that expect to be invoked via the inheriting class.
As with the above, you can either invoke the class methods using their full path (e.g.,
My::Class->Foreign::Class::method();), or you can
use baseso that you don't have to use the full path. Again, using the full path is faster.
Class::Singleton is an example of this type of class.
- 3. Class methods that don't care how they are invoked (i.e., they don't make reference to the invoking class).
In this case, you can either use
use Object::InsideOut qw(Foreign::Class);for consistency, or use
use base qw(Foreign::Class);if (slightly) better performance is needed.
If you're not familiar with the inner workings of the foreign class such that you don't know if or which of the above exceptions applies, then the formulaic approach would be to first use the documented method for foreign inheritance (i.e.,
use Object::InsideOut qw(Foreign::Class);). If that works, then I strongly recommend that you just use that approach unless you have a good reason not to. If it doesn't work, then try
use base.
For Perl 5.8.1 and later, this module fully supports threads (i.e., is thread safe), and supports the sharing of Object::InsideOut objects between threads using threads::shared.
To use Object::InsideOut in a threaded application, you must put
use threads; at the beginning of the application. (The use of
require threads; after the program is running is not supported.) If object sharing is to be utilized, then
use threads::shared; should follow.
If you just
use threads;, then objects from one thread will be copied and made available in a child thread.
The addition of
use threads::shared; in and of itself does not alter the behavior of Object::InsideOut objects. The default behavior is to not share objects between threads (i.e., they act the same as with
use threads; alone).
To enable the sharing of objects between threads, you must specify which classes will be involved with thread object sharing. There are two methods for doing this. The first involves setting a
::shared variable (inside a
BEGIN block) for the class prior to its use:
use threads;
use threads::shared;
$My::Class::shared = 1;
use My::Class;
The other method is for a class to add a
:SHARED flag to its
use Object::InsideOut ... declaration:
package My::Class; {
use Object::InsideOut ':SHARED';
When either sharing flag is set for one class in an object hierarchy, then all the classes in the hierarchy are affected.
If a class cannot support thread object sharing (e.g., one of the object fields contains code refs [which Perl cannot share between threads]), it should specifically declare this fact:
package My::Class; {
use Object::InsideOut ':NOT_SHARED';
However, you cannot mix thread object sharing classes with non-sharing classes in the same class hierarchy:
use threads;
use threads::shared;
package My::Class; {
use Object::InsideOut ':SHARED';
package Other::Class; {
use Object::InsideOut ':NOT_SHARED';
package My::Derived; {
use Object::InsideOut qw(My::Class Other::Class); # ERROR!
Here is a complete example with thread object sharing enabled:
use threads;
use threads::shared;
package My::Class; {
use Object::InsideOut ':SHARED';
# One list-type field
my @data :Field('Accessor' => 'data', 'Type' => 'List');
package main;
# New object
my $obj = My::Class->new();
# Set the object's 'data' field
$obj->data(qw(foo bar baz));
# Print out the object's data
print(join(', ', @{$obj->data()}), "\n"); # "foo, bar, baz"
# Create a thread and manipulate the object's data
my $rc = threads->create(
sub {
# Read the object's data
my $data = $obj->data();
# Print out the object's data
print(join(', ', @{$data}), "\n"); # "foo, bar, baz"
# Change the object's data
$obj->data(@$data[1..2], 'zooks');
# Print out the object's modified data
print(join(', ', @{$obj->data()}), "\n"); # "bar, baz, zooks"
return (1);
# Show that changes in the object are visible in the parent thread
# I.e., this shows that the object was indeed shared between threads
print(join(', ', @{$obj->data()}), "\n"); # "bar, baz, zooks"
Usage With
It is possible to use Exporter to export functions from one inside-out object class to another:
use strict;
use warnings;
package Foo; {
use Object::InsideOut 'Exporter';
our @EXPORT_OK = qw(foo_name);
sub foo_name
return (__PACKAGE__);
package Bar; {
use Object::InsideOut 'Foo' => [ qw(foo_name) ];
sub get_foo_name
return (foo_name());
package main;
print("Bar got Foo's name as '", Bar::get_foo_name(), "'\n");
Note that the
BEGIN block is needed to ensure that the Exporter symbol arrays (in this case
@EXPORT_OK) get populated properly.
Usage With
require and
Object::InsideOut usage under mod_perl and with runtime-loaded classes is supported automatically; no special coding is required.
Singleton Classes
A singleton class is a case where you would provide your own
->new() method that in turn calls Object::InsideOut's
->new() method:
package My::Class; {
use Object::InsideOut;
my $singleton;
sub new {
my $thing = shift;
if (! $singleton) {
$singleton = $thing->Object::InsideOut::new(@_);
return ($singleton);
This module uses
Exception::Class for reporting errors. The base error class for this module is
OIO. Here is an example of the basic manner for trapping and handling errors:
my $obj;
eval { $obj = My::Class->new(); };
if (my $e = OIO->caught()) {
print(STDERR "Failure creating object: $e\n");
I have tried to make the messages and information returned by the error objects as informative as possible. Suggested improvements are welcome. Also, please bring to my attention any conditions that you encounter where an error occurs as a result of Object::InsideOut code that doesn't generate an Exception::Class object. Here is one such error:
- Invalid ARRAY/HASH attribute
This error indicates you forgot the following in your class's code:
use Object::InsideOut qw(Parent::Class ...);
You cannot overload an object to a scalar context (i.e., can't
You cannot use two instances of the same class with mixed thread object sharing in same application.
Cannot use attributes on subroutine stubs (i.e., forward declaration without later definition) with
package My::Class; {
sub method :Private; # Will not work
sub _automethod :Automethod
# Code to handle call to 'method' stub
Due to limitations in the Perl parser, you cannot use line wrapping with the
:Field attribute.
If a set accessor accepts scalars, then you can store any inside-out object type in it. If its
Type is set to
HASH, then it can store any blessed hash object.
It is possible to hack together a fake Object::InsideOut object, and so gain access to another object's data:
my $fake = bless(\do{my $scalar}, 'Some::Class');
$$fake = 86; # ID of another object
my $stolen = $fake->get_data();
Why anyone would try to do this is unknown. How this could be used for any sort of malicious exploitation is also unknown. However, if preventing this sort of security issue a requirement, then do not use Object::InsideOut.
Returning objects from threads does not work:
my $obj = threads->create(sub { return (Foo->new()); })->join(); # BAD
Instead, use thread object sharing, create the object before launching the thread, and then manipulate the object inside the thread:
my $obj = Foo->new(); # Class 'Foo' is set ':SHARED'
threads->create(sub { $obj->set_data('bar'); })->join();
my $data = $obj->get_data();
There are bugs associated with threads::shared that may prevent you from using foreign inheritance with shared objects, or storing objects inside of shared objects.
For Perl 5.6.0 through 5.8.0, a Perl bug prevents package variables (e.g., object attribute arrays/hashes) from being referenced properly from subroutine refs returned by an
:Automethod subroutine. For Perl 5.8.0 there is no workaround: This bug causes Perl to core dump. For Perl 5.6.0 through 5.6.2, the workaround is to create a ref to the required variable inside the
:Automethod subroutine, and use that inside the subroutine ref:
package My::Class; {
use Object::InsideOut;
my %data;
sub auto :Automethod
my $self = $_[0];
my $name = $_;
my $data = \%data; # Workaround for 5.6.X bug
return sub {
my $self = shift;
if (! @_) {
return ($$data{$name});
$$data{$name} = shift;
For Perl 5.8.1 through 5.8.4, a Perl bug produces spurious warning messages when threads are destroyed. These messages are innocuous, and can be suppressed by adding the following to your application code:
$SIG{__WARN__} = sub {
if ($_[0] !~ /^Attempt to free unreferenced scalar/) {
print(STDERR @_);
A better solution would be to upgrade threads and threads::shared from CPAN, especially if you encounter other problems associated with threads.
For Perl 5.8.4 and 5.8.5, the "Storable" feature does not work due to a Perl bug. Use Object::InsideOut v1.33 if needed.
View existing bug reports at, and submit any new bugs, problems, patches, etc. to: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Object-InsideOut
Perl 5.6.0 or later
Exception::Class v1.22 or later
Scalar::Util v1.10 or later. It is possible to install a pure perl version of Scalar::Util, however, it will be missing the weaken() function which is needed by Object::InsideOut. You'll need to upgrade your version of Scalar::Util to one that supports its
XS code.
Test::More v0.50 or later (for installation)
Object::InsideOut Discussion Forum on CPAN: http://www.cpanforum.com/dist/Object-InsideOut
Annotated POD for Object::InsideOut: http://annocpan.org/~JDHEDDEN/Object-InsideOut-1.44/lib/Object/InsideOut.pm
Inside-out Object Model: http://www.perlmonks.org/?node_id=219378, http://www.perlmonks.org/?node_id=483162, http://www.perlmonks.org/?node_id=515650, Chapters 15 and 16 of Perl Best Practices by Damian Conway
Abigail <perl AT abigail DOT nl> for inside-out objects in general.
Damian Conway <dconway AT cpan DOT org> for Class::Std.
David A. Golden <dagolden AT cpan DOT org> for thread handling for inside-out objects.
Dan Kubb <dan.kubb-cpan AT autopilotmarketing DOT com> for
:Chained methods.
Jerry D. Hedden, <jdhedden AT cpan DOT org>
Copyright 2005, 2006 Jerry D. Hedden. All rights reserved.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


text:
Remember that three and a half uninterrupted days? It turns out, not so much. I was under the impression that since Filbert had this huge project to do, he was taking Monday through Wednesday off to work on it, until he came to join us in Iowa for Thanksgiving. I should have known better. He took Monday off and really only had half of Monday because since I was in Iowa with the kids, he had to go to the boys' parent teacher conferences that afternoon and go bowling that evening. (Bowling is sacred, don't even suggest that he take a night off.) I discovered through phone conversations the misunderstanding regarding the work schedule and then lived in fear for the rest of the trip. (Bonus: Cashew potty-trained while we were there. Yay. (Peanut is still not trained, but he no longer plays Picasso with his poop, either. Yay.)) We still managed to have a lovely Thanksgiving and Filbert returned home early to continue work on the closet.
I arrived home to see my lovely new floors and my missing closet. I still don't have a closet. I haven't been able to put the house back together after moving the furniture out of three different rooms. Chaos reigns (remember in Get Smart the evil agency was called Kaos?). And that chaos led us into the Christmas season and prevented any sign of Christmas from appearing in our house. We did get the small tree put up, but the cats keep knocking it over and chewed through one of the light strings. (Oh, by the way, this summer we got 2 kittens. They are named Lavender and Fairbanks. The kids love them.) So anyway, I was feeling kinda bummed about the lack of Christmas cheer in the house, but I have resolved to do better next year and also, Filbert is not allowed to start any new projects until all the projects he has started are completed. Oh, that's right, I forgot, part of the reason we chose the timing of Thanksgiving to do this project was because Filbert thought the bunk beds that he is building would be finished by then. Unfortunately, the work of getting three rooms ready for new flooring delayed the completion of the bunk beds. They're still not done, either. (Filbert is not a loser. I told him I would say that, because he was concerned that people might think he was a loser. He's not a loser, though.)
So anyway, we muddled toward Christmas and tried to look forward time with family and friends instead of focusing on the chaos. We've also had to deal with the escalation of Peanut's PWS related food-seeking behaviors and our fridge has a shiny new padlock on it. Peanut has been getting up early in the morning before anyone wakes and has delighted in finding many ways to strike fear into our hearts. He's really too smart for his own good.
On the 23rd, Filbert and I and his sister, Lisa, and her husband took their grandparents out for a special Christmas breakfast. While there, we got a hugely unexpected (and generous!!!) wad of cash from the Greats to spend on Christmas. Later that day, Lisa and I thought it would be a fabulous idea to go shopping with the money to get stuff for the kids that they could open in front of the Greats on Christmas. (Really, we just wanted to get away from the kids, between us we have a 7 year old, a 6 year old, a 5 year old, a 4 year old, a 3 year old and a 2 year old, and one of us is pregnant, and I'll give you a hint, it's not me.) I asked the kids what they wanted and got various answers, but Peanut was quite emphatic about wanting a "blue guy". I didn't know what this was. I got him a light saber, instead.
On the 24th, we opened presents with the family and Peanut again expressed his wish for a "blue guy" and we finally figured out that he wanted a Perry the Platypus toy. Since Filbert had to go out and exchange the
At 6:30 this morning, Walnut came into our bedroom and said Peanut's up and I think he's opening presents. We rushed to the family room and every stinking, last present was unwrapped. When asked why he did this, Peanut just replied, I can't find the blue guy, where's the blue guy?

subset: commoncrawl


text:
Notes from Game 7 and B game
There was initially some concern when right-hander Brandon Morrow exited his start in a "B" game against the Phillies in Clearwater. He had only thrown two innings and fired off 32 pitches. The schedule sheet inside the Jays clubhouse indicated he was down to throw three frames.
Then, Marc Rzepczynski went three innings with 49 pitches. After that? Brett Cecil made his spring debut and needed 46 pitches for two innings. After years of watching pitcher after pitcher go down with injury for the Jays, it seemed that the only explanation for Morrow's short outing was that he was hurt.
Nope. He's fine.
"We're changing up the scheduling a little bit," Morrow explained. "I'm going to throw three on Sunday. So, three days off and then throw."
The Blue Jays are in the midst of setting their rotation for the regular season. That is why Morrow will be pitching on short rest next time out. Don't look now, but if you count backwards from Opening Day, Shaun Marcum would get the nod for the first start of the regular season.
It says here that the planned rotation right now is Marcum, Ricky Romero, Morrow, Marc Rzepczynski and Brian Tallet. The only way I see that changing is if Dustin McGowan proves he's healthy and ready. In that scenario, Tallet could wind up back in the bullpen. I still think it's more realistic that McGowan opens the year on the disabled list.
I asked manager Cito Gaston if it was too soon to say if any pitchers were separating themselves from others in this competition. His reply?
"I think it's too early," Gaston said. "We've kind of got our mind on who's going to be in that rotation right now. There's so many guys you can stretch out and so many guys you can't. We kind of have an idea, unless something changes, something happens, somebody gets hurt and you have to move somebody else in there. But, we're kind of prepared for that, too."
The reality is that lefty Brett Cecil, with his left thumb setback, is behind the other pitchers now and would likely have to really out-pitch them down the stretch to make the Opening Day staff. Lefty David Purcey has not been particularly sharp in his spring outings so far, with a 9.00 ERA in two short appearances. Lefty Dana Eveland has looked good, so there's always the chance he remains quietly in the mix as a darkhorse candidate.
But, back to Morrow…
He logged two innings and allowed no runs on three hits. Really, it should've been two hits. One in the first inning clearly looked like an error on the second baseman, but it got the hometeam discount and was ruled an infield single. Morrow also struck out two and continued to work on his changeup.
"It's something that I didn't really throw much out of the bullpen," Morrow said. "With guys really gearing up for my fastball, that's always how it's been, I think my ability to throw that for a strike is going to be probably the biggest key for me, definitely. If I'm throwing that in 2-0, 2-1 counts, that makes a world of difference. It's really been night and day, those days that I've been able to go out there and throw changeups for strikes"
Morrow also saw seven left-handed hitters among the eight he faced. Considering the wealth of left-handed pop in the American League East, Morrow did not mind getting in some extra work with lefties at the plate.
"They're always going to try to stack the lineup left-handed against a right-handed power pitcher," he said. "Every team [in the East] has got the left-handed power hitters and that's good practice to be throwing your changes. … In the past, I've had trouble kind of with that guy in the batter's box, kind of leaking your body towards him.
"With a right-hander I'm able to stay closed a little bit. It's always nice to see those guys in there to work on what you need to work on."
THE REAL… As promised, Gaston gave Mike McCoy some playing time in the outfield, putting him in center field after Vernon Wells exited on Wednesday in the A game in Dunedin. McCoy can play second, short and third and can also man all three outfield spots. With his speed, too, the Jays are giving him a good look for a bench role.
"I had never seen him play," Gaston said. "He played for Cuz, Nick Leyva, down in Mexico last year and Nick kind of recommended this kid and told me he could play out there. So, we want to see if he can play out there. He plays all three. We know he can play all three positions in the infield and plus here's a kid that stole 40 bases. So he's done a good job already in Spring Training."
TRAVEL SQUAD: Making the trip to Port Charlotte on Thursday (and hoping it doesn't rain) are: Shawn Camp, Willie Collazo, Ray Gonzalez, Rommie Lewis, Shaun Marcum, Brad Mills, Steven Register, Casey Fien, JP Arencibia, Jose Molina, Kyle Phillips, David Cooper, Brad Emaus, Jarrett Hoffpauir, Mike McCoy, John McDonald, Jesus Merchan, Randy Ruiz, Brett Wallace, Joey Gathright, Chris Lubanski, Jorge Padilla. Marcum and Mills are each down to throw three innings.
BIRD FEED: Lefty Brett Cecil made his spring debut in the "B" game, but was limited to throwing fastballs and changeups. The Jays did not want him throwing curves or sliders, hoping to prevent risking having him open the cut on his left thumb. In two innings, Cecil allowed three runs (all on a homer) on four hits with four strikeouts and one walk. … In his three-inning showing in the "B" game, Rzepczynski allowed one run on two hits with five strikeouts and one hit batsmen. After throwing 30 pitches (18 strikes) in his first inning of work, Zep threw 19 (16) the rest of the way. … In the "A" game against the Phillies, leadoff man extraordinaire Jose Bautista went 2-for-3 with his third homer of the spring. … Kyle Drabek got the start against the Phillies and logged two shutout innings. See bluejays.com for more on his outing against his former team. … Closing candidates Jason Frasor, Scott Downs and Kevin Gregg each logged an inning. Only Gregg (1 run, three hits) have up a run.
GOING DEEP: In the ninth inning at Dunedin Stadium, Cody Ransom belted a long homer off Jays lefty David Purcey. It was announced as Ransom's first homer of the spring. But, wait! It was Ransom who took Cecil yard for a three-run bomb earlier in the day in the "B" game. That blast? We didn't see it land. Pretty sure it cleared Frenchy's, which sits beyond the left-field bleachers at Bright House Field.
GOING HOME: The lone run that Rzepczynski allowed came during a bases-loaded jam in his first inning. With no outs, Zep induced a grounder to first base prospect Brett Wallace, who quickly fired to the shortstop to hopefully turn a double play. With Dwayne Wise running to first, though, turning two wasn't going to happen. In hindsight, Wallace should have thrown home to halt the run, and he had plenty of time. As it happened, Zep struck out the next two batters to escape without any more damage.
"The play was probably home," Gaston said. "There's a kid over there playing. Wallace, he's over there. He was told later, I think the play is at home. You don't have a chance for a double play. That's just not knowing. He doesn't know Wise. He hasn't played against Wise. Somebody like [Lyle] Overbay knows Wise and knows you're not going to get a double play with Wise."
Wallace was acquired in the Roy Halladay deal in December and was moved to first base after playing third as a pro. Gaston said that the play in question had more to do with Wallace's knowledge of the runners than with his experience at the position, though.
QUOTABLE: "I wish I had a gun on him. He was probably throwing harder than I've ever seen him. When he does that, he's in trouble. He got the ball down and he got back to the old Rzepczynski, as far as I'm concerned." — Gaston, on Zep's "B" Game outing
For complete Blue Jays coverage this spring, make sure you're reading bluejays.com and following me on Twitter at @MLBastian. You can also find spring photos on TwitPic.com.
var OutbrainPermaLink='http://mlblogsmlbastian.files.wordpress.com/2010/03/wallace4-thumb-250×357-18454711.jpgarchives/2010/03/anthopoulos_discusses_mcgowan.html';
var OB_Template = "mlbblogs";
var OB_demoMode = false;
var OBITm = "1241712535489";
var OB_langJS ='http://widgets.outbrain.com/lang_en.js';
if ( typeof(OB_Script)!='undefined' )
else {
var OB_Script = true;
var str = ";
2 Comments
I'm really glad Mike McCoy played for Nick Leyva in winter ball, I'm sure Leyva was impressed since McCoy hit .304/.413/.374 with 41 walks, 35 K's and 26 stolen bases in 59 games-sort of like how he did in AAA the last 3 years. What impresses me the most about him, is his walk to k ratio-it is impressive.
He is versatile with what must be a great plate discipline to pretty much consistently walk more times than he strikes out, and in 202 games played in the outfield in the minors he's only had one error. I think he should be our starting short stop and lead off hitter, his high obp will be great, and yes he's 28, BUT that also gives us time to develop another short stop.
McCoy is sure looking like the real McCoy to me and is a much better option, imo, than Reed or Gathright. I realize spots are tight, but it would be nice to see McCoy, Snider, Ruiz and Dopirak all come north, of course to bring all 4 would mean we either have to trade Overbay or Gonzalez. On the other hand none of Overbay, Gonzalez, Reed or Gathright will help us win next year or the year after and Snider, McCoy, Ruiz and Dopirak will and as a result they should be here.
It says a lot when a bunch of team mates stand around to watch Drabek's bull pen session and numerous sports casters who watch him pitch rave about him. This kid is going to be here sooner than later and he looks like he's going to be a good one.( it's in his genes).
In two years from now, I think we'll look back and recognize the Doc trade was the best trade ever completed by the Jays.
I also think Seattle is going to wake up sometime this year and realize they really got robbed in the League/Morrow trade. I think Morrow is going to seriously come into his own this year and be a dominant pitcher, particularly if he can keep throwing that change up for strikes.
Fast forward to 2011 and a rotation of Drabek, Morrow, Romero, Marcum and someone else ( hopefully McGowan) could be and likely will be the best rotation in baseball. When you think of Cecil, Jenkins, Stewart, Alvarez, Mills and Rzep knocking on the door, it almost boggles one's mind at the high quality starting pitching depth we have.
Add to that Hill, Lind, Snider, Wallace, Arencibia and Wells along with potentially Dopirak, Encarnacion, a good lead off hitter-maybe McCoy, strong bullpen and all I can say is it's becoming a real nice time to be a Blue Jays fan.
Give this team a year or so and then bring on the Sox, Tampa Bay and the Yanks is all I say.
I like McCoy a lot, mainly because of his versatility and speed. I expect coming off the bench that his bat might suffer a bit, but he brings good D and base running and can play 6 different positions. It would be really neat if he could take over the starting shortstop position, because at 28, he still has 6-8 good years left if he stays healthy, and he is old enough that he won't make too many "rookie" mistakes.


text:
Main navigation | Main content
|Professor Lindsay Glesener with Undergraduate Kendra Bergstedt.
|Richard Anderson
The undergraduate physics program at Minnesota offers a flexible, real-world approach to the physics major. We offer physics major programs that prepare you for careers in engineering and applied physics, computer applications, secondary school teaching, or biomedical sciences as well as one that gives an excellent preparation of physics graduate work. In addition we offer a liberal arts physics major, the liberal arts degree for the modern world. Each of these programs is tailored to your specific needs by the careful choice of technical electives chosen in consultation with your physics advisor.
Physics learning is a process that involves intellectual engagement and hands-on experience. Imagination, creativity, real world problem solving, communication, and team work are an important part of the process. We emphasize the important connection between reality and theory with a substantive laboratory component to every physics program. Each includes a year long course called Methods in Experimental Physics in which students get experience using modern experimental equipment, including computer interfacing, and end up designing, constructing, analyzing, and presenting the results of their own experiment. All physics majors are encouraged to participate in our research groups working on the frontiers of knowledge. These positions often offer financial support either through the University's UROP program or directly from the research group. Physics majors, especially those interested in pursuing an advanced degree or a career in teaching, can also obtain a teaching assistant position in the department.
Email email@example.com to talk to an advisor.
You can find out all the details of the program in the Undergraduate Handbook.


text:
Nutrition Facts
Ingredients and Preparation
- Combine garlic, rosemary, parsley, and pine nuts in a blender or food processor until finely chopped. Drizzle in oil, and continue blending until it forms a thick paste. Transfer to a bowl, and stir in salt and pepper.
- Coat both sides of the steaks with paste. Cover and refrigerate 30 minutes to overnight.
- Prepare indoor or outdoor grill. Grill the steaks 7-9 minutes per side, or until they reach desired degree of doneness.
- Let meat rest 5 minutes, and then serve.


text:
This is not an offer for credit and should be used for estimation purposes only based on the information you provided. You should not base your decision on this estimate alone. Title, registration, tax and other fees, and personal circumstances such as employment status and personal credit history, were not considered in the calculations.
The all-new Tiger Explorer XRx packs immense power and linear torque from its signature 1,215 cc triple engine and is optimized for road riding with cast wheels, ABS, traction control, and Brembo monobloc four-piston radial calipers at the front, and a single 282 mm disc, two-piston sliding caliper at the rear. The XRx also incorporates Triumph's electronically controlled Semi-Active Suspension system (TSAS) continuously adjusts the suspension settings as you ride, delivering the best control, comfort and riding experience on any surface.
Three new selectable Rider Modes; Road, Rain, and Off-Road, incorporate different setting for ABS, traction control and throttle maps, each optimized to suit the selected mode for maximum control, comfort and rider engagement.
With an electronically adjustable screen, hand guards, heated grips and cruise control as standard the Tiger Explorer XRx gives you more of what you want from an adventure bike.
Front - Twin 305 mm floating discs, radially mounted Brembo monobloc 4-piston calipers, switchable ABS
Rear - Single 282 mm disc, Nissin 2-piston sliding caliper, switchable ABS
Front - 19 x 3 in. cast aluminum alloy, 10-spoke
Rear - 17 x 4.5 in. cast aluminum alloy, 10-spoke
Front - 120/70 R19
Rear - 170/60 R17
Without Mirrors - 55.1 in. (1,400 mm)
Without Mirrors with Higher Screen Position - 57.9 in. (1,470 mm)
Handlebars - 32.7 in. (830 mm)
Handlebars with Handguards - 36.6 in. (930 mm)
Tubular steel trellis
Swingarm - Single-sided, cast aluminum alloy with shaft drive
Front - WP 48 mm upside down forks; electronically adjustable damping; 7.5 in. (190 mm) travel
Rear - WP monoshock, electronically adjustable semi-active damping, automatic preload adjustment; 7.6 in. (193 mm) travel
Crystal White
Jet Black


text:
Two Rooms
by Lee Blessing
Play Description
(The following description is as appears on the back cover of the Dramatists Play Service, Inc. edition of the play)
The two rooms of the title are a windowless cubicle in Beirut where an American hostage is being held by Arab terrorists and a room in his home in the United States which his wife has stripped of furniture so that, at least symbolically, she can share his ordeal. In fact the same room serves for both and is also the locale for imaginary conversations between the hostage and his wife, plus the setting for the real talks she has with a reporter and a State Department official. The former, an overly ambitious sort who hopes to develop the situation into a major personal accomplishment, tries to prod the wife into taking umbrage at what he labels government ineptitude and inaction, while the State Department representative is coolly efficient, and even dispassionate, in her attempt to treat the matter with professional detachment. It is her job to try to make the wife aware of the larger equation of which the taking of a hostage is only one element, but as the months inch by it becomes increasingly difficult to remain patient, and when the official lifts the reporter's passport to prevent him from going to Beirut, the wife is goaded to speak out against government policy and, in so doing, triggers the tragic series of events that brings the play to its startling conclusion. In the end there are no winners, only losers, and the sense of futility and despair that comes when people of good will realize that logic, compassion and fairness have become meaningless when dealing with those who would commit such barbarous acts so willingly.
"…the playwright's eye is penetrating…Mr. Blessing…reaffirms his authority with timely political questions" —The New York Times
"…a compact and powerful exploration of the hostage-taking of Beirut." —Drama-Logue


text:
5-alpha reductase inhibitors interfere
with the effect of certain male hormones (androgens) on the prostate. This
slows the growth of the prostate and can even cause it to become smaller, which
may help improve the symptoms of
benign prostatic hyperplasia (BPH).
since prostate size does not always correspond to the severity of a man's
symptoms, these medicines will not give satisfactory results in every case.
When you stop taking the medicine, symptoms usually
5-alpha reductase inhibitors are used to keep symptoms of BPH from getting worse. They are also used to reduce the risk of being unable to urinate (urinary retention) and to prevent surgery for BPH.
5-alpha reductase inhibitors are also used to treat the symptom of blood in the urine because of BPH.
5-alpha reductase inhibitors are not
recommended for men who have BPH symptoms without a noticeably enlarged prostate.
5-alpha reductase inhibitors may be prescribed for men who have bothersome,
moderate symptoms of BPH.
Most men who use 5-alpha reductase
inhibitors report about a 3-point decrease in their
American Urologic Association (AUA) symptom index.
This change represents a noticeable improvement in symptoms.1
5-alpha reductase inhibitors also decrease the risk of
complications, such as being unable to urinate (urinary retention). And they make it
less likely that you will need surgery.2
It may take 6 to 12 months before you notice that your symptoms have improved.
Using a combination of an alpha-blocker with a
5-alpha reductase inhibitor long-term may help your symptoms more than either medicine
Side effects may include:
These side effects may go away after a year or more of taking the medicine.
It is possible that 5-alpha reductase inhibitors are linked to an increased risk for high-grade prostate cancers. But more research is needed.
See Drug Reference for a full list of side effects. (Drug Reference is
not available in all systems.)
5-alpha reductase inhibitors
reduce the size of the prostate. But since a smaller size does not always
relieve symptoms, these medicines will not give satisfactory results
in every case. When you stop taking the medicine, symptoms usually
5-alpha reductase inhibitors lower prostate-specific
antigen (PSA) levels. Because PSA levels are used to detect early-stage
prostate cancer, men interested in taking a 5-alpha reductase inhibitor might
consider the following:
5-alpha reductase inhibitors are not recommended for treatment of BPH symptoms
in men who do not have an enlarged prostate.1
The medicine must be taken for the rest of your life to prevent the
symptoms from coming back.
This medicine should not be used by men
who plan to father a child, because there is a small chance that the medicine could
cause a birth defect. Women who are pregnant or might become pregnant should
not handle broken or crushed tablets of finasteride or dutasteride.
Complete the new medication information form (PDF)(What is a PDF document?) to help you understand this medication.
CitationsAUA Practice Guidelines Committee (2010). AUA guideline on management of benign prostatic hyperplasia. Chapter 1: Guideline on the management of benign prostatic hyperplasia (BPH). Available online: http://www.auanet.org/content/guidelines-and-quality-care/clinical-guidelines.cfm?sub=bph.McNicholas T, Kirby R (2011). Benign prostatic hyperplasia, search date July 2009. Online version of BMJ Clinical Evidence: http://www.clinicalevidence.com.Roehrborn CG, et al. (2008). The effects of
dutasteride, tamsulosin and combination therapy on lower urinary tract symptoms
in men with benign prostatic hyperplasia and prostatic enlargement: 2-year
results from the CombAT study. Journal of Urology,
179(2): 616–621.
Last Revised:
March 5, 2012
Healthwise Staff
Medical Review:
E. Gregory Thompson, MD - Internal Medicine & J. Curtis Nickel, MD, FRCSC - Urology
This information does not replace the advice of a doctor. Healthwise, Incorporated disclaims any warranty or liability for your use of this information. Your use of this information means that you agree to the Terms of Use. How this information was developed to help you make better health decisions.
To learn more visit Healthwise.org
© 1995-2012 Healthwise, Incorporated. Healthwise, Healthwise for every health decision, and the Healthwise logo are trademarks of Healthwise, Incorporated.


text:
SANTA CLARA, Calif., March 12 (UPI) -- The San Francisco 49ers finalized two deals Tuesday, acquiring wide receiver Anquan Boldin from Baltimore and trading quarterback Alex Smith to Kansas City.
San Francisco picked up Boldin from the Ravens for a sixth-round choice in the updating NFL draft, and sent Smith to the Chiefs and new Coach Andy Reid in return for an undisclosed 2013 draft choice -- but apparently not the overall No. 1 pick owned by the Chiefs -- and a conditional pick in 2014.
Boldin had 22 catches for 380 yards and four touchdowns in the last post-season. That includes six receptions for 104 yards and the first touchdown in Super Bowl XLVII, where the Ravens beat the 49ers 34-31.
Boldin was with Baltimore for three seasons after playing in Arizona for seven. He has 772 receptions for 10,165 yards and 58 touchdowns in 140 NFL games.
Smith had been the 49ers' starting quarterback until he was hurt last season and lost the position to Colin Kaepernick. With Kaepernick at quarterback, the 49ers advanced to the Super Bowl.
Smith, 28, was the first overall pick in the 2005 draft and passed for 14,280 yards and 81 touchdowns in eight seasons in San Francisco.
"We would like to thank Alex for his contributions to the 49ers organization over the past eight years," said 49ers General Manager Trent Baalke. "He is a true professional who represented the 49ers with class on and off the field."
Kansas City was 2-14 last season behind Matt Cassel and Brady Quinn, who split the starting duties.


text:
The Huguenot Nursery School is a private, non-profit preschool serving Pelham and its surrounding communities. The school is non-sectarian and welcomes families of all backgrounds and cultures. Our core philosophy focuses on the development of the "whole child" through their cognitive, physical, emotional and social development in a nurturing and comfortable environment.
We provide half-day and full-day programs for children ages two through five. Children in the 2's classes have a maximum of 9 students, with one qualified lead teacher and an assistant teacher. Children in the in the 3's and 4's classes have a maximum of 14 children, with one qualified lead teacher and an assistant teacher.
Founded by Huguenot Memorial Church in 1992, the school is licensed by the New York State office of Children and Family Services.
Please click here if you would like to schedule a tour of the school.


text:
We're sorry, but we currently have no tickets available for this event.
Check out our full selection of Blues and Jazz tickets or sign up to be notified when tickets are available and exclusive discounts!
Lil' Ed Tickets & Show Date Info
With cheap Lil' Ed tickets from online vendor Vividseats.com, you can be seated front row and dead center singing along with all of your favorite numbers. We've become the largest independently owned and managed ticket marketplace in the nation, due to our enormous selection of high quality sports, theater and concert tickets. Check out our ticket inventory and you can find the Lil' Ed tickets you've always dream of, at a price that's extremely affordable. All you need to do is locate the show date you want to attend by referencing the Lil' Ed concert tour schedule we've posted above, and then click on the button labeled "Find Your Seats." Even if you're interested in touring the nation and attending every one of the Lil' Ed concert tour dates, Vividseats.com can most likely supply you great seating options. The great thing about shopping for any concert tickets through our website is that we allow you to choose your own seats. Use the interactive seating chart diagram to play around with your seating choices before you make your purchase of Lil' Ed concert tickets. Don't forget to use the Vivid Seats Live Chat function above if you run into any difficulties or have any questions while trying to purchase Lil' Ed tickets.


text:
Robt Stone [ME] LLC is a leading EPC, Infrastructure and Maintenance Contractor for Pipeline and Process Plant in the Oil and Gas sector in the MENA Region.
We are a diversified Company having execution experience in countries like UAE, Qatar and New Zealand. We continue investing in Construction equipment, and latest technologies to keep pace with demanding requirement of construction industry. Our multi task experienced manpower is our core strength of our company growth of 98% since inception in last 8 years.


text:
BISD releases statements, but not documents
Accusations that Beaumont Independent School District Taylor Career and Technology Center Principal Thomas Amons nixed the campus' Adult Cosmetology program rather than allow admission to a student he thought was gay were answered by school district administrators this week. After the Sept. 13 Examiner story "Sexuality the deciding factor in program's closure" garnered national attention from numerous outlets such as the Huffington Post and MSN news, BISD blamed monetary concerns for the program ending. Still, the community is demanding proof the program was actually cut due to "budget constraints" as the district claims.
Although run as a viable program for more than a decade, the Adult Cosmetology class offered through BISD's Taylor Career and Technology Center ended Sept. 13, according to class instructor Cequana Clark, because Principal Thomas Amons would rather close the program than allow admission to a man he thought was gay after a brief encounter with the prospective student on the first day of class Sept. 10.
According to Clark, who has headed the adult cosmetology program since 2009 at BISD, Amons told her that he never wanted to see "flamboyantly gay guys" in the BISD program like the men enrolled at similar area programs. Clark said she knew Amons was serious when 22-year-old Kwmane Gray tried to enroll in the program.
"As soon as we got a student that (Amons) thought was gay, that was the end," she said.
Clark said Principal Amons, a man who also serves as a deacon at Antioch Missionary Baptist Church, was adamant that Gray would not be allowed to enroll and instructed her to tell Gray he wasn't welcome in the program. After bringing another instructor in on the conversation, Amons said he would consult BISD's legal representation on how to proceed, Clark said.
"The next day (Sept. 11), (Amons) told me that the legal department said he couldn't exclude (Gray) based on his sexual preference, but that as the principal of the school he could decide to no longer offer the program. He said the last day would be Thursday, Sept. 13."
The closing of the program not only affected new enrollees like Gray, Clark added, because four students were already enrolled in the program when classes were set to resume Sept. 10. Clark said enrollment has steadily increased in the program since she started in 2009, jumping from two students to eight when the call came down to close the program. Clark, who aside from her BISD job holds positions as a pastor of a Groves church and owner of a salon in Beaumont, said the majority of the students attending the adult program were single mothers.
"At the very least, I'd like to see Mr. Amons apologize to that young man and to allow those already entered in the program to finish their instruction to get licensed," Clark said, adding the right thing to do would be to continue the program and allow Gray to enter."This is like a hate crime," prospective student Gray told The Examiner. Gray had never openly addressed the matter of his sexual orientation before Amons allegedly targeted the former Lamar University honor student, but he has since been thrust into the limelight after he learned from the BISD instructor that the entire program was closed due to Gray's interest in taking classes at the campus. "He never even talked to me," Gray said. "He just judged me."
Attempts to reach Amons at his office were unsuccessful. Multiple messages left with various BISD officials – communication representatives Jessie Haynes and Ron Reynolds, assistant superintendent Patria Lambert, and BISD legal counsel Melody Chappell – all went unreturned.
But in the days following publication of our first story, BISD released two different statements to various news organizations relating to the incident.
And that's not all. After the The Examiner published the original story Thursday, Sept. 13, Clark was asked to turn in her keys and receipt book, ending her employment with BISD. "We've decided to let you go," she says Principal Amons told her. "We don't need your services anymore."
Side two
BISD officials released a statement to some local news outlets Sept. 13 defending Amons' decision: "Due to budget restraints and no Beaumont ISD cosmetology graduates registering for the class, the Taylor Career center is no longer offering an extended courtesy evening cosmetology class for adults. Amons stressed that the high school cosmetology program at Taylor still exists. But he said the school can no longer afford to fund the part of the program serving non-BISD cosmetology program graduates."
Contrary to BISD's statement, however, the program instructor has documentation proving that at least one BISD Taylor Career Center graduate was continuing toward her license this semester in the adult program, and multiple students logged in for the evening classes as well.
Additionally, BISD's operating budget, approved Aug. 16, shows no change in the budget allotment for adult programs or adult night class instruction offered through the district for the 2012-13 school year, and only roughly a $1,000 reduction in the budget for the Taylor Career campus as a whole. The district-wide annual budget shows operating expenses for the program should have been covered through fiscal year 2013. BISD spokesman Ron Reynolds said the budget issues would be evident from documentation held at the Taylor Career Center, but those documents were as of yet unavailable for public review.
E-mail exchanges between instructor Clark and principal Amons from Aug. 24 show the school employees were in agreement on starting the first day of the adult class Sept. 10, more than a week after district administration approved this school year's budget.A day after releasing the first statement, BISD released a second version of its side of the story. In the new correspondence, officials announced the opening of a new adult cosmetology class to commence next month. The new program will double the tuition, but other details of the new program are vague.
Quest for information
Outraged observers from all over the world have joined a group that sprung up on Facebook demanding an investigation into Clark's allegations. The group, with more than 700 members, staged a protest at the BISD administration building Sept. 15, with dozens showing up to offer support for their efforts in forcing an investigation. Founding member Mo Boggan said none of the statements issued from BISD have swayed her position in her quest for the truth.
"In addition to (the original complaint), we now have other stories of this principal doing this sort of thing to other students," Boggan said. According to her, if the program was shut due to "budget issues," the information would be readily available. "I think it's a cop out," she said.
Further support for Boggan's group came in the form of a change.org petition signed by roughly 1,300 people from around the world calling for Amons' removal should the district be unable to prove budgetary concerns led to the program's cancellation.
BISD elected trustee Mike Neil said he has been investigating the allegations since he was made aware of the issue Sept. 13.
"I am very frustrated about what is happening," he said. "I have been asking questions in the background and am not satisfied with the answers I am getting. Our Communications Department's incompetence has allowed this situation to become a national embarrassment."
Neil requested an agenda item be added to the BISD meeting scheduled for Thursday, Sept. 20, allowing for the board of trustees to talk about the allegations in an open forum as a group. The meeting will be held at the BISD Administration Building, 3395 Harrison, starting at 7:15 p.m.
Board trustee Tom Neild said he, too, is looking into the allegations and takes the complaint very seriously.
"Everybody that I've talked to is just flabbergasted about this," he said. "There are so many questions about this issue and they really need to be addressed. If this was a budget situation, why wasn't our board told about it?
"I think it is a slap in the face to the public to say this program was cut because of budget issues."
Neild said he, too, has requested documentation to prove the program was cut due to budget woes, but according to him, those documents have not been provided. He added that the matter is a public issue, and the public deserves to see proof of BISD's statements.
"Just because BISD says it, doesn't mean people believe it," he said.
BISD Superintendent Dr. Timothy Chargois said it was "misinformation" that the program was closed to prevent a student from attending the adult cosmetology class because of a student's sexual preference. Gray, who was prevented from enrolling in the program although he pre-purchased materials for the course, said he would not be attending BISD's newly announced adult cosmetology class, which will still be offered at Amons' campus.
"(BISD) still has a problem," he said, adding that he wouldn't enroll in any program until Amons was relieved of his post and Clark was reinstated to her position in the district. He said, "They still have a heartless monster as the head of students."