Variables

 sub CLASS {
     my $x;             # private
     has my $y;         # read-only
     public my $z;      # public
 }

As of the moment, "has" and "public" only support scalar variables.

You can give the variables a default value by assigning to the whole declaration. For simple private variables this is easy; for read-only and public variables, it requires extra parentheses:

 sub CLASS {
     my $x         = 1;
     has(my $y)    = 2;
     public(my $z) = 3;
 }

To use these variables within the class, use their plain lexical name with the sigil. To use them outside the class, call them as methods. Given the class above:

 $obj->x;      # Illegal; private
 $obj->y;      # Ok, 2.
 $obj->z;      # Ok, 3.
 $obj->z = 32; # Write to $z.

This may be a little different from the usual "$obj->z(32)" syntax you might be used to. Trust me, this will grow on you.

Methods

 sub CLASS {
     method bark => sub {
         print "Woof!\n";
     };
 }

The invocant is still passed in as the first argument as in old-style OO. The fact is, though, that many times you won't need it, since you can reference the member variables without it. You still need it to call functions on yourself, though.

 sub CLASS {
     method chase_tail => sub {
         my ($self) = @_;
         $self->chase($self->find_tail);
     };
 }

Accessors

 sub CLASS {
     accessor 'number',
             get { print "Getting the number";  42; },
             set { print "Setting the number";  $_[0]->send($_[1]) };
 }
 print $obj->number;  # "Getting the number"  "42"
 $obj->number = 314;  # "Setting the number" ...

Inheritance

To inherit, use the "extends" keyword. It can take as an argument either a class name (make sure you quote it lest you confuse Perl) or an object. If you need to pass construction parameters to your superclass, just inherit from it as an object:

 sub CLASS {
     extends MySuperClass->new(@params);
 }

Constructors and Destructors

Destructors are a little different. Because of the magic that Class::Closure has to do to get them to work with inheritance, they have a special syntax:

 sub CLASS {
     destroy { print "Destructing object"; }
 }

Yep, that's all. And you heard me correctly, they work right with inheritance, unlike the standard "DESTROY" method.

FALLBACK

How does it work?

The "CLASS" sub that you defined in your package is actually called every time an object is created. That's right, so there's no need for a "BUILD" at all (but it makes things look cleaner). Class::Closure exports each one of these "keywords" into your namespace, and they are used right on the spot to construct the object each time.

Each object's member hash is actually a lexical scratchpad, and it keeps track of where it is, so you don't have to reference $self all the time. It has the added plus that each object in an inheritance heirarchy has it's own scratchpad, so you don't get variable name conflicts.

In more detail, when you call "new" on your package, it derives a new anonymous package for only that object. Then when you use "method" (or "has" or "public" or "attribute", which are really just wrappers around the same thing), it installs the sub you give into that symbol table position. These closure's aren't "cloned", but just referenced, so this doesn't take up the horrible amount of memory you might be thinking it does.

Then when all references to the object disappear, it uses Symbol's "delete_package" to clean out the anonymous package and free memory (and more importantly, call "DESTROY"s) associated with the object.

What does this all mean for you, the user? Since you understand that these "declarations" are just sub calls at object construction time, you can create your objects based on a dynamic template:

 sub CLASS {
     my ($class, $mode) = @_;

     if ($mode == 1) {
         method foo => sub { ... };
         method bar => sub { ... };
     }
     else {
         method foo => sub { ... };
         method bar => sub { ... };
     }
 }

That avoids a run-time check on each of the method calls, and makes things a little easier to read. There's all kinds of other fun stuff you can do.

Technical Notes / Bugs / Caveats / Etc.

"accessor"-like subs with arguments aren't yet supported, but there's nothing in the design that says they aren't allowed. I'm just lazy, and I'll happily add them upon request.

You might get in trouble if you try to define method names the same as the exported keyword names.

There are certainly more bugs, since this is complex, subtle, scary code. Bug reports/patches welcome.