Zydeco::Manual::01_ClassesRolesEtc - Classes, roles, and abstract classes
package Farming { use Zydeco; class Animal { has name; } role Milkable { method milk { say "giving milk..."; } } class Cow extends Animal with Milkable; } my $daisy = Farming->new_cow(name => "Daisy"); $daisy->milk();
The object-oriented programming paradigm, is based on the concept of "objects" which are structures representing real-world things or abstract ideas, containing data (a.k.a. attributes) and the code (a.k.a. methods) needed to operate on this data.
Most object-oriented programming languages, including Perl, are class-based. Each object is a member of a class, and it is the class where these attributes and methods are defined.
In Zydeco, you can create a class with the class keyword. The simplest class definition consists of class followed by a name for the class:
class
class Bucket;
It is possible to create a class without specifying a name, in which case Zydeco will think of a name and return it. However, as the class keyword is always a complete statement, you cannot do:
my $Bucket = class;
Instead you must wrap it in a do block:
do
my $Bucket = do { class; };
This is called an anonymous class.
Zydeco prefixes your class names with the package name.
package MyApp { use Zydeco; class Foo; # class name is "MyApp::Foo" class Foo::Bar; # class name is "MyApp::Foo::Bar" }
Prefixing a class name with "::" avoids this.
package MyApp { use Zydeco; class ::Foo; # class name is "Foo" class ::Foo::Bar; # class name is "Foo::Bar" }
When you've created a class, the next thing to do is create objects of that class. The class "Bucket" represents the concept of buckets, but objects of that class represent individual buckets.
For named classes in Perl, the typical way to create an object of class "Bucket" would be:
my $red_bucket = Bucket->new;
Zydeco does things a little differently though. Zydeco defines classes within "factory packages". Rather than asking the "Bucket" class for a new bucket object, you ask your factory package for a new bucket object.
package Farming { use Zydeco; class Bucket; } my $red_bucket = Farming->new_bucket;
For anonymous classes, the factory does not know how to make them, so to instantiate them ("instantiate" means "create an instance of"), you call new on the class directly.
new
my $Bucket = do { class; }; my $red_bucket = $Bucket->new;
You can check to see if an object is a Bucket using the isa method.
isa
if ( $object->isa("Farming::Bucket") ) { ...; }
But notice this hard-codes the name of your package ("Farming"). We don't like hard-coding stuff, so a better way is to make use of the "Farming::Types" type library. While you define the "Farming" factory package, Zydeco will be at work in the background, defining "Farming::Types".
use Farming; use Farming::Types -is; if ( is_Bucket $object ) { ...; }
With anonymous classes, you need to stick with isa though.
if ( $object->isa($Bucket) ) { ...; }
A role is a way to bundle up a collection of behaviours that can then be imported (a.k.a. consumed) by a class. Goats, sheep, and cows are all milkable, so in our farming example, we might want to define the behaviour for a milkable animal in a "Milkable" role which the "Cow", "Goat", and "Sheep" classes can all consume.
Roles are defined with the role keyword which mostly uses the same syntax as the class keyword.
role
package Farming { use Zydeco; role Milkable; role Wooly; class Cow with Milkable; class Goat with Milkable, Wooly; class Sheep with Milkable, Wooly; }
Roles cannot be instantiated like classes can. You can create a new "Cow" object which will be "Milkable", but you can't directly create a "Milkable" object.
Anonymous roles are possible.
my $Milkable = do { role; };
Consuming anonymous roles is a little tricky.
class Cow { with {"::$Milkable"}; }
The braces mean that the role should be evaluated as a block. The leading "::" is required because you don't want the prefix to be added to the role name.
The equivalent of isa for roles is does.
does
if ( $daisy->does("Farming::Milkable") ) { ...; }
But like with checking isa, it's desirable to avoid hard-coding that "Farming" everywhere. Better to use a type check.
use Farming; use Farming::Types -is; if ( is_Milkable $daisy ) { ...; }
The type check functions look so much more elegant anyway.
If you have a role name as a string, you can consume it by putting it in braces.
For some roles, there may not be any real "behaviour" associated with them. For example, piglets and rabbits are adorable.
package Farming { class Piglet with Adorable?; class Rabbit with Adorable?; }
This just tags the "Rabbit" and "Piglet" classes with the "Adorable" role which can be checked using does or is_Adorable, without us having to declare the "Adorable" role explicitly. It's just a shortcut for:
is_Adorable
package Farming { role Adorable; class Piglet with Adorable; class Rabbit with Adorable; }
Inheritance allows you make one class into a subclass of another.
For example, all piglets are pigs, so if we have an existing "Pig" class, we can say that "Piglet" is a subclass of that.
package Farming { class Pig; class Piglet extends Pig; }
Objects of class Piglet are also objects of class Pig.
use Farming; use Farming::Types -is; my $oinker = Farming->new_piglet; is_Piglet($oinker); # ==> true is_Pig($oinker); # ==> true
Any behaviours defined by the "Pig" class will be inherited by the Piglet class, but the "Piglet" class may define its own unique behaviours too, or override behaviour from the parent class.
It is possible to both inherit and consume at the same time:
class Piglet extends Pig with Adorable?;
Extending anonymous classes is much like consuming anonymous roles.
class Piglet { extends { "::" . "Pig" }; }
Multiple inheritance is supported though it is often considered bad design.
# potentially a bad idea class Car; class Plane; class FlyingCar extends Car, Plane; # usually a better idea role RoadVehicle; role AirVehicle; class Car with RoadVehicle; class Plane with AirVehicle; class FlyingCar with RoadVehicle, AirVehicle;
It it possible to mark a class as abstract. An abstract class is one that, like a role, cannot be instantiated, but can be inherited from.
For example, it may be desirable to have an abstract class "Animal" for our farmyward, which all other animals inherit from, but disallow creating "Animal" objects directly. We do this using the abstract keyword, which is just a prefix for class.
abstract
package Farming { use Zydeco; role Milkable; abstract class Animal; class Horse extends Animal; class Cow extends Animal with Milkable; class Pig extends Animal; class Piglet extends Pig with Adorable?; class Sheep extends Animal with Milkable; class Goat extends Animal with Milkable; class Rabbit extends Animal with Adorable? }
You might notice this getting a little repetitive. Zydeco allows you to nest subclass definitions within their parent class as a shortcut.
package Farming { use Zydeco; role Milkable; abstract class Animal { class Horse; class Cow with Milkable; class Pig { class Piglet with Adorable?; } class Sheep with Milkable; class Goat with Milkable; class Rabbit with Adorable? } }
If you prefix a class name with a plus sign, the class name will be prefixed with its parent class.
package MyApp { class Foo { # class name is "MyApp::Foo" class +Bar { # class name is "MyApp::Foo::Bar" class +Baz::Bat; # class name is "MyApp::Foo::Bar::Baz::Bat" } } }
This even works with extends.
extends
package MyApp { class Foo; # class name is "MyApp::Foo" class +Bar extends Foo; # class name is "MyApp::Foo::Bar" }
You can specify a version number for a class or role.
role Foo 1.0; class Bar 1.1 with Foo;
If it's not just a simple decimal number, you may use the version keyword inside the class or role block.
version
role Foo { version "1.0.0"; } class Bar with Foo { version "1.1.0"; }
You can check a class or role's version using the VERSION method:
VERSION
my $daisy = MyApp->new_cow; say MyApp::Cow->VERSION; say $daisy->VERSION; $daisy->VERSION('0.5'); # will die if version is too low
You can give a default version when you load Zydeco.
package MyApp { use Zydeco version => '1.0'; class Foo; class Bar 1.1; }
Zydeco allows you to specify the authority/author of a class or role.
class Foo { authority "cpan:TOBYINK"; } role Bar { authority "github:tobyink"; } abstract class Baz { authority "mailto:tobyink@cpan.org"; }
Authorities should be URLs, though "cpan:" and "github:" pseudo-URLs are also allowed.
say $Foo::AUTHORITY;
You can give a default authority when you load Zydeco.
package MyApp { use Zydeco version => '1.0', authority => 'cpan:TOBYINK'; class Foo; class Bar 1.1; }
Although it has been rather glossed over, two ways of expressing inheritance and composition have been shown; one where they are declared inside a block, and one where they are declared outside the block.
class Foo::Bar { extends Foo; with Bar; ...; } class Foo::Bar extends Foo with Bar { ...; }
By and large, they are equivalent, however, the form where they are inside the block allows extends or with to accept a block of code instead of a bareword.
with
class Foo::Bar { extends { join "o" => "F", "o" }; with { $ENV{USE_BAZ} ? "Baz" : "Bar" }; ...; }
It also allows them to occur multiple times in any order.
class Foo::Bar { extends Foo1; with Bar; ...; with Baz; extends Foo2; }
The form where they are outside the block allows is or isa to be used as synonyms for extends, and does as a synonym for with.
is
class Foo::Bar is Foo does Bar { ...; }
This is less Moose-like and more Raku-like.
Although the syntax is more limited, they may still be used to inherit from multiple base classes, or compose multiple roles, using commas.
class Foo::Bar extends Foo1, Foo2 with Bar, Baz { ...; }
Zydeco uses Moo to build your classes and roles by default, and all classes ultimately inherit from Moo::Object.
my $daisy = MyApp->new_cow; if ( $daisy->isa('Moo::Object') ) { ...; }
You can use Moose or Mouse as an alternative to Moo.
package MyApp { use Zydeco; class Foo { toolkit Moose; } role Bar { toolkit Mouse; } }
Extensions for Moo, Moose, and Mouse can be loaded by putting them in parentheses afterwards.
class Foo { toolkit Moose (StrictConstructor, BuildArgs); }
This will load Moose, MooseX::StrictConstructor, and MooseX::BuildArgs in your class. The names in the parentheses are prefixed with "MooX::", "MooseX::", or "MouseX::" as appropriate. If you wish to avoid prefixing, prefix them with "::".
class Foo { toolkit Mouse ( ::MooseX::StrictConstructor ); } # I don't know why you'd want to use MooseX::StrictConstructor # in a Mouse class, but Zydeco doesn't stop you!
Not all extensions to Moo, Moose, and Mouse will work well with Zydeco. Extensions that export additional keywords or install wrappers around already-exported keywords are unlikely to work. Extensions that poke at their caller via the metaobject protocol will usually work.
In this chapter, we looked at the following keywords:
abstract class
authority
toolkit
The structure and behaviour of objects is defined by classes. In the next chapter we will see how classes can define the structure of their objects.
Zydeco::Manual::02_Attributes - Powerful and concise attribute definitions
Toby Inkster <tobyink@cpan.org>.
This software is copyright (c) 2020 by Toby Inkster.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
To install Zydeco, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Zydeco
CPAN shell
perl -MCPAN -e shell install Zydeco
For more information on module installation, please visit the detailed CPAN module installation guide.