Return::MultiLevel provides a way to return immediately from a
deeply nested call stack. This is similar to exceptions, but
exceptions don't stop automatically at a target frame (and they
can be caught by intermediate stack frames). In other words,
this is more like setjmp(3)/longjmp(3) than die.
Return::Type allows you to specify a return type for your subs. Type constraints
from any Type::Tiny, MooseX::Types or MouseX::Types type library are supported.
The simple syntax for specifying a type constraint is shown in the "SYNOPSIS"
[1]. If the attribute is passed a single type constraint as shown, this will be
applied to the return value if called in scalar context, and to each item in the
returned list if called in list context. (If the sub is called in void context,
type constraints are simply ignored.)
[1] http://search.cpan.org/dist/Return-Type/lib/Return/Type.pm#SYNOPSIS
Rinci is a set of extensible, language-neutral metadata specifications for your
code (functions/methods, variables, packages, classes, and so on). It allows
various helper tools, from code generator to web middleware to documentation
generator to other protocols, to act on your code, making your life easier as a
programmer. Rinci also allows better interoperability between programming
languages. It is geared towards dynamic scripting languages like Perl, Python,
Ruby, PHP, JavaScript, but is not limited to those languages.
Sub::Current makes available a function ROUTINE(), that returns a code
reference pointing at the currently executing subroutine.
In a special block (BEGIN, END, CHECK, INIT, and UNITCHECK in Perl 5.10)
this function will return undef.
Outside of a special block (that is, at the top level of a program)
ROUTINE() will return undef as well.
This module provides one function, delete_sub, that deletes the
subroutine whose name is passed to it. (To load the module without
importing the function, write use Sub::Delete();.)
This does more than simply undefine the subroutine in the manner of
undef &foo, which leaves a stub that can trigger AUTOLOAD (and,
consequently, won't work for deleting methods). The subroutine is
completely obliterated from the symbol table (though there may be
references to it elsewhere, including in compiled code).
Sometimes you want roles. You're not sure about Moose, Mouse, Moo and
what was that damned Squirrel thing anyway? Then there's Class::Trait,
but it has a funky syntax and the maintainer's deprecated it in favor
of Moose::Role and you really don't care that it handles overloading,
instance application or has a workaround for the SUPER:: bug. You
think a meta-object protocol sounds nifty, but you don't understand
it. Maybe you're not sure you want the syntactic sugar for object
declaration. Maybe you've convinced your colleagues that roles are a
good idea but they're leery of dragging in Moose (your author has had
this happen more than once and heard of others making the same
complaint). Sometimes you just want good old-fashioned roles which let
you separate class responsibility from code reuse.
SDL Perl is a package of Perl modules that provide both functional
and object oriented interfaces to the Simple DirectMedia Layer for
Perl 5. This package takes some liberties with the SDL API, and
attempts to adhere to the spirit of both the SDL and Perl.
Role::HasMessage is an extremely simple role. A class that includes
Role::HasMessage is promising to provide a message method that
returns a string summarizing the message or event represented by
the object. It does not provide any actual behavior.
Role::Identifiable::HasIdent is an incredibly simple role. It adds
a required ident attribute that stores a simple string, meant to
identify exceptions.
Role::Identifiable::HasTags adds the ability for your class and its
composed parts (roles, superclasses) as well as instances of it to
contribute to a pool of tags describing each instance.
Role composition can be thought of as much more clever and meaningful multiple
inheritance. The basics of this implementation of roles is:
- If a method is already defined on a class, that method will not be composed in
from the role.
- If a method that the role "requires" to be implemented is not implemented,
role application will fail loudly.
Unlike Class::C3, where the last class inherited from "wins," role composition
is the other way around, where first wins. In a more complete system (see Moose)
roles are checked to see if they clash. The goal of this is to be much simpler,
hence disallowing composition of multiple roles at once.