For each attribute, a read-write accessor is created unless a subroutine of that name already exists:

$obj->name; # getter
$obj->name( "John Doe" ); # setter

Attribute names must be valid subroutine identifiers or an exception will be thrown.

You can specify lazy defaults by defining attributes with a hash reference. Keys define attribute names and values are constants or code references that will be evaluated when the attribute is first accessed if no value has been set. The object is passed as an argument to a code reference.

If your class does not already inherit from some class, then Class::Tiny::Object will be added to your @ISA to provide new and DESTROY.

If your class does inherit from something, then no additional inheritance is set up. If the parent subclasses Class::Tiny::Object, then all is well. If not, then you'll get accessors set up but no constructor or destructor. Don't do that unless you really have a special need for it.

Define subclasses as normal. It's best to define them with base, parent or superclass before defining attributes with Class::Tiny so the @ISA array is already populated at compile-time:

If a reference is passed as a single argument, it must be able to be dereferenced as a hash or an exception is thrown.

Unknown attributes in the constructor arguments will be ignored. Prior to version 1.000, unknown attributes were an error, but this made it harder for people to cleanly subclass Class::Tiny classes so this feature was removed.

You can define a BUILDARGS method to change how arguments to new are handled. It will receive the constructor arguments as they were provided and must return a hash reference of key/value pairs (or else throw an exception).

If your class or any superclass defines a BUILD method, it will be called by the constructor from the furthest parent class down to the child class after the object has been created.

It is passed the constructor arguments as a hash reference. The return value is ignored. Use BUILD for validation, checking required attributes or setting default values that depend on other attributes.

Class::Tiny provides a DESTROY method. If your class or any superclass defines a DEMOLISH method, they will be called from the child class to the furthest parent class during object destruction. It is provided a single boolean argument indicating whether Perl is in global destruction. Return values and errors are ignored.

Likewise, a hash reference of all valid attributes and default values (or code references) may be retrieved with the get_all_attribute_defaults_for class method. Any attributes without a default will be undef.

The import method uses two class methods, prepare_class and create_attributes to set up the @ISA array and attributes. Anyone attempting to extend Class::Tiny itself should use these instead of mocking up a call to import.

When the first object is created, linearized @ISA, the valid attribute list and various subroutine references are cached for speed. Ensure that all inheritance and methods are in place before creating objects. (You don't want to be changing that once you create objects anyway, right?)

I wanted something so simple that it could potentially be used by core Perl modules I help maintain (or hope to write), most of which either use Class::Struct or roll-their-own OO framework each time.

Object::Tiny and Object::Tiny::RW were close to what I wanted, but lacking some features I deemed necessary, and their maintainers have an even more strict philosophy against feature creep than I have.

I also considered Class::Accessor, which has been around a long time and is heavily used, but it, too, lacked features I wanted and did things in ways I considered poor design.

I looked for something else on CPAN, but after checking a dozen class creators I realized I could implement exactly what I wanted faster than I could search CPAN for something merely sufficient.

In general, compared to most things on CPAN (other than Object::Tiny), Class::Tiny is smaller in implementation and simpler in API.

Specifically, here is how Class::Tiny ("C::T") compares to Object::Tiny ("O::T") and Class::Accessor ("C::A"):

Moose and Moo are both excellent OO frameworks. Moose offers a powerful meta-object protocol (MOP), but is slow to start up and has about 30 non-core dependencies including XS modules. Moo is faster to start up and has about 10 pure Perl dependencies but provides no true MOP, relying instead on its ability to transparently upgrade Moo to Moose when Moose's full feature set is required.

By contrast, Class::Tiny has no MOP and has zero non-core dependencies for Perls in the support window. It has far less code, less complexity and no learning curve. If you don't need or can't afford what Moo or Moose offer, this is intended to be a reasonable fallback.

That said, Class::Tiny offers Moose-like conventions for things like BUILD and DEMOLISH for some minimal interoperability and an easier upgrade path.