Ports Search

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.