++ Very nice start to a tutorial -- and on a topic that continues to need it, as recent criticism suggests.

I have a few corrections and comments.

sub new {
   my $self = shift;
   register( $self );
[download]

It should be:

sub new {
   my $class = shift;
   my $self = register( $class );
[download]

That's the longhand approach for clarity of what the arguments mean. my $self = register( shift ) would be shorthand.

When provided with a single, non-reference argument, register treats it as a class name and will return a reference to an anonymous scalar blessed into the given class. Thus, considering this question:

$manager->{phone} = '555-1313';

# {{what is the behavior of this??}}
[download]

If you use the new() example I give above, this will die with an error as $manager is a reference to a scalar, not a hash.

Note that if you use an anonymous hash reference (using an alternate style of register):

sub new {
   my $class = shift;
   my $self = register( {}, $class );  # register does the bless, too
[download]

Then $manager->{phone} = '555-1313' will work as usual, but will have nothing to do with the value retrieved by $manager->phone().

Aren't inside-out objects fun?

public   birthday => my %birthday, { set_hook =>; \&_set_birthday };
[download]

Extra semicolon. set_hook => \&_set_birthday

Return values from get_hook are ignored; the accessor expects that get_hook will simply modify '$_'.

This is incorrect. The behavior isn't symmetric with set_hook. For get_hook, $_ is a copy of the attribute -- you can modify it without affecting what is stored. The return value of the get_hook is returned from the accessor. Your example just happens to work because the last thing you do is $_ = strftime and that is what gets returned. You could also have done this:

sub _get_birthday {
    strftime '%m/%d/%Y', localtime( $_ ); # but NOT just localtime()
}
[download]

But again, your tutorial has a nice build-up from simple to more advanced concepts, around a well-defined example (date storage). With some editing and clarifications from feedback here and elsewhere in the thread, it will probably be something I'm happy to either link to in the Class::InsideOut documentation or possibly even add as Class::InsideOut::Tutorial.

One thing you might want to clarify a bit more is the id() function and its importance in generating the unique ID for a object.

I also wouldn't describe Class::Std as "deprecated" -- I'm not a big fan, but it's certainly in use. It is very good for dealing with complex class hierarchies (as one would expect of a module by TheDamian) but I think it errs by not being more fundamentally robust.

My YAPC::NA 2006 presentation is another potential reference you could add.