# PODNAME: Class::InsideOut::Manual::About
# ABSTRACT: guide to this and other implementations of the inside-out technique

__END__

=pod

=encoding UTF-8

=head1 NAME

Class::InsideOut::Manual::About - guide to this and other implementations of the inside-out technique

=head1 VERSION

version 1.14

=head1 DESCRIPTION

This manual provides an overview of the inside-out technique and its
application within C<<< Class::InsideOut >>> and other modules.  It also provides a
list of references for further study.

=head2 Inside-out object basics

Inside-out objects use the blessed reference as an index into lexical data
structures holding object properties, rather than using the blessed reference
itself as a data structure.

  $self->{ name }        = "Larry"; # classic, hash-based object
  $name{ refaddr $self } = "Larry"; # inside-out

The inside-out approach offers three major benefits:

=over

=item *

Enforced encapsulation: object properties cannot be accessed directly
from outside the lexical scope that declared them

=item *

Making the property name part of a lexical variable rather than a hash-key
means that typos in the name will be caught as compile-time errors (if
using L<strict>)

=item *

If the memory address of the blessed reference is used as the index,
the reference can be of any type

=back

In exchange for these benefits, robust implementation of inside-out
objects can be quite complex.  C<<< Class::InsideOut >>> manages that complexity.

=head2 Philosophy of C<<< Class::InsideOut >>>

C<<< Class::InsideOut >>> provides a set of tools for building safe inside-out classes
with maximum flexibility.

It aims to offer minimal restrictions beyond those necessary for robustness of
the inside-out technique.  All capabilities necessary for robustness should be
automatic.  Anything that can be optional should be.  The design should not
introduce new restrictions unrelated to inside-out objects, such as attributes
and C<<< CHECK >>> blocks that cause problems for C<<< mod_perl >>> or the use of source
filters for syntactic sugar.

As a result, only a few things are mandatory:

=over

=item *

Properties must be based on hashes and declared via C<<< property >>>

=item *

Property hashes must be keyed on the C<<< Scalar::Util::refaddr >>>

=item *

C<<< register >>> must be called on all new objects

=back

All other implementation details, including constructors, initializers and
class inheritance management are left to the user (though a very simple
constructor is available as a convenience).  This does requires some additional
work, but maximizes freedom.  C<<< Class::InsideOut >>> is intended to be a base class
providing only fundamental features.  Subclasses of C<<< Class::InsideOut >>> could be
written that build upon it to provide particular styles of constructor,
destructor and inheritance support.

=head2 Other modules on CPAN

=over

=item *

L<Object::InsideOut> -- This is perhaps the most full-featured, robust
implementation of inside-out objects currently on CPAN.  It is highly
recommended if a more full-featured inside-out object builder is needed.
Its array-based mode is faster than hash-based implementations, but black-box
inheritance is handled via delegation, which imposes certain limitations.

=back

=over

=item *

L<Class::Std> -- Despite the name, this does not reflect currently known best
practices for inside-out objects.  Does not provide thread-safety with CLONE
and doesn't support black-box inheritance.  Has a robust
inheritanceE<sol>initialization system.

=back

=over

=item *

L<Class::BuildMethods> -- Generates accessors with encapsulated storage using
a flyweight inside-out variant. Lexicals properties are hidden; accessors must
be used everywhere. Not thread-safe.

=back

=over

=item *

L<Lexical::Attributes> -- The original inside-out implementation, but missing
some key features like thread-safety.  Also, uses source filters to provide
Perl-6-like object syntax. Not thread-safe.

=back

=over

=item *

L<Class::MakeMethods::Templates::InsideOut> -- Not a very robust
implementation. Not thread-safe.  Not overloading-safe.  Has a steep learning
curve for the Class::MakeMethods system.

=back

=over

=item *

L<Object::LocalVars> -- My own original thought experiment with 'outside-in'
objects and local variable aliasing. Not safe for any production use and offers
very weak encapsulation.

=back

=head2 References for further study

Much of the Perl community discussion of inside-out objects has taken place on
Perlmonks (L<http://perlmonks.org>).  My scratchpad there has a fairly
comprehensive list of articles
(L<http://perlmonks.org/index.pl?node_id=360998>).  Some of the more
informative articles include:

=over

=item *

Abigail-II. "Re: WhereE<sol>When is OO useful?". July 1, 2002.
L<http://perlmonks.org/index.pl?node_id=178518>

=item *

Abigail-II. "Re: Tutorial: Introduction to Object-Oriented Programming".
December 11, 2002. L<http://perlmonks.org/index.pl?node_id=219131>

=item *

demerphq. "Yet Another Perl Object Model (Inside Out Objects)". December 14,
2002. L<http://perlmonks.org/index.pl?node_id=219924>

=item *

xdg. "Threads and fork and CLONE, oh my!". August 11, 2005.
L<http://perlmonks.org/index.pl?node_id=483162>

=item *

jdhedden. "Anti-inside-out-object-ism". December 9, 2005.
L<http://perlmonks.org/index.pl?node_id=515650>

=back

=head1 SEE ALSO

=over

=item *

L<Class::InsideOut>

=item *

L<Class::InsideOut::Manual::Advanced>

=back

=head1 AUTHOR

David Golden <dagolden@cpan.org>

=head1 COPYRIGHT AND LICENSE

This software is Copyright (c) 2006 by David A. Golden.

This is free software, licensed under:

  The Apache License, Version 2.0, January 2004

=cut