SIMOTRONE WEB PAGE » Perl

Mojolicious respond_to

Simotrone — Sat, 04 Feb 2012 16:21:07 +0000

Mentre la bufera di neve torna ad affliggere Bologna, io giochicchio con Mojolicious e mi segno un paio di note.

Per provare a scimmiottare un’interfaccia REST seria, m’ero costruito a colpi di given un controller che generava la risposta in funzione dell’attributo format dello stash (solite cose: html, json, xml); per altro, poichè non stavo usando “the right way” mi stavo pure scontrando con alcune difficoltà implementative (1).

In realtà esiste un comodissimo metodo respond_to che già compie questa selezione internamente (il codice).

Dato questo codice:

#!/usr/bin/env perl

use Mojolicious::Lite;

get ‘/test’ => sub {

        my $self = shift;

        my $data = { a => 1, b => 2, c => 3 };

        $self->respond_to(

                json => { json => $data },

                html => { text => $self->dumper($data) }

        );

};

app->start;

possiamo ottenere diverse risposte:

(1) sim@titanio:/tmp$ mojo get -v -H ‘Accept: text/html’‘http://localhost:3001/test’

GET /test HTTP/1.1

User-Agent: Mojolicious (Perl)

Accept: text/html

Content-Length: 0

Host: localhost:3001
HTTP/1.1 200 OK

X-Powered-By: Mojolicious (Perl)

Content-Type: text/html;charset=UTF-8

Connection: keep-alive

Date: Sat, 04 Feb 2012 15:33:23 GMT

Server: Mojolicious (Perl)

Content-Length: 39
{

  ‘c’ => 3,

  ‘a’ => 1,

  ‘b’ => 2

}

—————————–

(2) sim@titanio:/tmp$ mojo get -v -H ‘Accept: application/json’ ‘http://localhost:3001/test’

GET /test HTTP/1.1

User-Agent: Mojolicious (Perl)

Accept: application/json

Content-Length: 0

Host: localhost:3001
HTTP/1.1 200 OK

X-Powered-By: Mojolicious (Perl)

Content-Type: application/json

Connection: keep-alive

Date: Sat, 04 Feb 2012 15:34:01 GMT

Server: Mojolicious (Perl)

Content-Length: 19
{"c":3,"a":1,"b":2}

—————————

(3) sim@titanio:/tmp$ mojo get -v -H ‘Accept: text/plain’ ‘http://localhost:3001/test’GET /test HTTP/1.1

User-Agent: Mojolicious (Perl)

Accept: text/plain

Content-Length: 0

Host: localhost:3001
HTTP/1.1 204 No Content

X-Powered-By: Mojolicious (Perl)

Connection: keep-alive

Date: Sat, 04 Feb 2012 15:34:40 GMT

Server: Mojolicious (Perl)

Content-Length: 0

————————–

(4) sim@titanio:/tmp$ mojo get -v -H ‘Accept: text/plainz’ ‘http://localhost:3001/test’

GET /test HTTP/1.1

User-Agent: Mojolicious (Perl)

Accept: text/plainz

Content-Length: 0

Host: localhost:3001
HTTP/1.1 200 OK

X-Powered-By: Mojolicious (Perl)

Content-Type: text/html;charset=UTF-8

Connection: keep-alive

Date: Sat, 04 Feb 2012 15:35:15 GMT

Server: Mojolicious (Perl)

Content-Length: 39
{

  ‘c’ => 3,

  ‘a’ => 1,

  ‘b’ => 2

}

Le prime tre sono corrette, poichè dati determinati header ottengo le risposte giuste:

text/html – 200
application/json – 200
text/plain – 204 – nessuna rappresentazione corretta

Il quarto a mio avviso è un fail, o meglio una scelta discutibile: invece che riconoscere l’header sbagliato e mandare a spendere il client con un 204, gli serviamo html.

Benchè alla fine di quel metodo venga restituito un 204 se il $target non esite (#L423), il gioco “sporco” accade 20 righe prima dove nel caso la rappresentazione passata non venga individuata, si ricade nella situazione di default (html di solito). Il problema a questo punto si incrocia con la possibilità che Mojolicious non abbia dentro di se la rappresentazione corretta benchè sia comune (openoffice, pdf – che forse ora sono stati inseriti, non so), cosa che può portare a conclusioni di default anche quando la rappresentazione richiesta è corretta ma non presente nei tipi di Mojo. In ogni caso, si può sempre aggiungere qualcosa ai MIME.

Ho comunque poi scoperto che la cosa è stata discussa in passato ed è stato deciso così.
Well, basta saperlo.

PS: Io avrei lasciato i client mal fatti nel loro brodo, ma tant’è – probabilmente non capisco bene le implicazioni.

Note:
(1) Le rotte in Mojolicious permettono di selezionare il formato utilizzando un array reference

get ‘/formats’ => [format => [‘html’,‘xml’]] => sub { };

sim@titanio:/tmp$ perl myapp.pl routes -v

/formats  GET  formats  ^/formats\.(xml|html)$

ma, come si vede dalla regex, questo fa sì che la rotta “pulita” diventi “/formats.” che non è proprio quello che si vuole, di solito.

Moose::Roles

Simotrone — Wed, 18 Jan 2012 22:29:14 +0000

Ho rispolverato alcuni appunti cartacei relativi i Ruoli di Perl Moose che riporto qui.

I ruoli rappresentano comportamenti condivisi fra le classi
La classe fa ciò che dice il ruolo.
I ruoli non sono classi; infatti i ruoli non si ereditano e non si istanziano.
I ruoli vengono consumati da classi o da altri ruoli.
I ruoli sono composti in una classe con la funzione with.
Tutti i metodi, modificatori, attributi definiti in un ruolo sono aggiunti direttamente alla classe che consuma il ruolo.
Attributi e metodi appariranno come se fossero definiti nella classe.
Una sottoclasse della classe consumata (cioè con il ruolo) eredita tutti questi metodi/attributi.

package Breakable;
use Moose::Role;
has ‘is_broken’ => (

      is  => ‘rw’,

      isa => ‘Bool’,

);
sub break {

      my $self = shift;

      print "I broke\n";

      $self->is_broken(1);

}

package Car;
use Moose;

with ‘Breakable’;
has ‘engine’ => (

      is  => ‘ro’,

      isa => ‘Engine’,

);

my $car = Car->new( engine => Engine->new );

print $car->is_broken ? ‘Busted’ : ‘Still working’;   # Still working

$car->break;                                          # I broke

print $car->is_broken ? ‘Busted’ : ‘Still working’;   # Busted

$car->does(‘Breakable’)

Riferimenti:

Moose::Role
Moose::Manual::Roles

Visualizzare utf-8 con Perl

Simotrone — Fri, 02 Dec 2011 06:39:52 +0000

Trovata qua una riga di comando che mostra un po’ di caratteri utf-8 con Perl.

$ perl -CS -e ‘

    for ($i = 128; $i < 11_620; $i++) {

        print chr $i, $i%30 ? " " : "\n$i "

    };

    print "\n"

 ’

DBIC->create e relazioni

Simotrone — Wed, 02 Nov 2011 06:25:00 +0000

Ho già parlato di DBIx::Class.

Avendo result source con relazioni si possono ottenere risultati interessanti.

Esistono gli oggetti Folk ed Email, ove l’oggetto Folk sia in relazione con molteplici oggetti Email (folk has_many emails).

package My::Schema::Result::Folk;

[…]

__PACKAGE__->has_many(‘emails’,‘My::Schema::Result::Email’,‘id’);

E’ possibile creare un record scrivendo i dati dell’oggetto/i relativo/i in un arrayref.

my $folks_rs = $schema->resultset("Folk");

my $new_folk = $folks_rs->create({

        name   => ‘Test folk’,

        emails => [

                {

                        email   => ‘mail@casa.name’,

                        comment => ‘Test mail casalinga’,

                },

                {

                        email   => ‘mail@azienda.org’,

                        comment => ‘Test mail aziendale’,

                },

        ],

});

E ci si libera di tutto con un bel

$new_folk->delete

Codice e output (con DBIC_TRACE attivo).

#!/usr/bin/perl
use strict;

use warnings;

use My::Schema;

use DBIx::Class;
my $schema   = My::Schema->connect("dbi:mysql:dbname=xxx","aaa","bbb");

my $folks_rs = $schema->resultset("Folk");
my $new_folk = $folks_rs->create({

        name   => ‘Test folk’,

        emails => [

                { email => ‘mail@casa.name’, comment => ‘Test mail casalinga’ },

                { email => ‘mail@azienda.org’, comment => ‘Test mail aziendale’ },

        ],

});

show_folk($new_folk->id);

$new_folk->delete;
sub show_folk {

        my ($id) = @_;

        my $folk = $folks_rs->find($id);

        my @emails = map { $_->email } $folk->emails;

        print " ".$folk->name, " [$id]\n ", join("\n ",@emails) , "\n";

}

$ DBIC_TRACE=1perl dbic_test.pl
BEGIN WORK

INSERT INTO folks ( name) VALUES ( ? ): ‘Test folk’

INSERT INTO emails ( comment, email, id) VALUES ( ?, ?, ? ): ‘Test mail casalinga’, ‘mail@casa.name’, ’134′

INSERT INTO emails ( comment, email, id) VALUES ( ?, ?, ? ): ‘Test mail aziendale’, ‘mail@azienda.org’, ’134′

COMMIT
SELECT me.id, me.name, me.surname, me.birth, me.gender, me.created, me.updated, me.active FROM folks me WHERE ( me.id = ? ): ’134′

SELECT me.id, me.email, me.comment FROM emails me WHERE ( me.id = ? ): ’134′

 Test folk [134]

 mail@azienda.org

 mail@casa.name

BEGIN WORK

DELETE FROM folks WHERE ( id = ? ): ’134′

SELECT me.id, me.email, me.comment FROM emails me WHERE ( me.id = ? ): ’134′

DELETE FROM emails WHERE ( email = ? ): ‘mail@azienda.org’

DELETE FROM emails WHERE ( email = ? ): ‘mail@casa.name’

COMMIT

(Come si vede chiaramente con quel codice, le fasi di inserimento e selezione dei dati avvengono in due momenti distinti (ci sono due blocchi BEGIN/COMMIT infatti).

Perl debugger come interprete interattivo

Simotrone — Sat, 29 Oct 2011 08:24:12 +0000

Tempo addietro mi è stato chiesto se Perl aveva un interprete interattivo, e risposi di no.

In effetti si può però usare un trucco che ne mette uno a disposizione (con anche qualche feature) sfruttando il debugger del linguaggio.

Dato uno script pinco.pl è possibile debuggarlo lanciando il comando col flag -d:

$ perl -d pinco.pl

Dunque, come ottenere un interprete?

$ perl -d -e 1

Questo comando lancia il debugger su uno script (-e) inesistente, e da quel momento in poi possiamo usare tutti gli strumenti di Perl (print per stampare valori, use per caricare moduli) più tutti gli strumenti del debugger (x per avere un dump delle strutture dati, b per creare un breakpoint) e così via.

Meglio di una gomitata in un occhio, invero.

Un video a riguardo l’ha girato Gabor Szabo.

Pod::Strip

Simotrone — Mon, 10 Oct 2011 05:19:02 +0000

Metodo grezzissimo per strippare il pod dal modulo perl e stampare il codice.

sim@idrogeno:/tmp$ cat /usr/share/perl5/path/al/modulo.pm | perl -MPod::Strip -e ‘

my $p=Pod::Strip->new();

    my $podless;

    $p->output_string(\$podless);

    my @rows = <>;

    my $text = join("",@rows);

    $p->parse_string_document($text);

    print $podless

‘ | a2ps

Module builderz

Simotrone — Thu, 06 Oct 2011 05:25:52 +0000

Volevo annotarmi le differenze tra i vari modi per creare una distro software.

Pacchetti sfruttati: module-starter con ExtUtils::MakeMaker, Module::Build, Module::Install e h2xs.

sim@idrogeno:/tmp$ module-starter --author=sim
          --email=xxx@xxxxx.xxx --module=Test::Build --mb

Added to MANIFEST: Build.PL
Added to MANIFEST: Changes
Added to MANIFEST: ignore.txt
Added to MANIFEST: lib/Test/Build.pm
Added to MANIFEST: MANIFEST
Added to MANIFEST: README
Added to MANIFEST: t/00-load.t
Added to MANIFEST: t/boilerplate.t
Added to MANIFEST: t/manifest.t
Added to MANIFEST: t/pod-coverage.t
Added to MANIFEST: t/pod.t
Created starter directories and files

sim@idrogeno:/tmp$ module-starter --author=sim
          --email=xxx@xxxxx.xxx --module=Test::Install --mi

Added to MANIFEST: Changes
Added to MANIFEST: ignore.txt
Added to MANIFEST: lib/Test/Install.pm
Added to MANIFEST: Makefile.PL
Added to MANIFEST: MANIFEST
Added to MANIFEST: README
Added to MANIFEST: t/00-load.t
Added to MANIFEST: t/boilerplate.t
Added to MANIFEST: t/manifest.t
Added to MANIFEST: t/pod-coverage.t
Added to MANIFEST: t/pod.t
Created starter directories and files

sim@idrogeno:/tmp$ module-starter --author=sim
          --email=xxx@xxxxx.xxx --module=Test::EUMM --eumm

Added to MANIFEST: Changes
Added to MANIFEST: ignore.txt
Added to MANIFEST: lib/Test/EUMM.pm
Added to MANIFEST: Makefile.PL
Added to MANIFEST: MANIFEST
Added to MANIFEST: README
Added to MANIFEST: t/00-load.t
Added to MANIFEST: t/boilerplate.t
Added to MANIFEST: t/manifest.t
Added to MANIFEST: t/pod-coverage.t
Added to MANIFEST: t/pod.t
Created starter directories and files

sim@idrogeno:/tmp$ h2xs -XAn Test::H2xs

Defaulting to backwards compatibility with perl 5.12.4
If you intend this module to be compatible with earlier perl
versions, please specify a minimum perl version with the -b
option.

Writing Test-H2xs/lib/Test/H2xs.pm
Writing Test-H2xs/Makefile.PL
Writing Test-H2xs/README
Writing Test-H2xs/t/Test-H2xs.t
Writing Test-H2xs/Changes
Writing Test-H2xs/MANIFEST

Tutti e 4 i modi scrivono i file Changes, MANIFEST, README, il package principale della lib e il test corrispondente.
Le tre distribuzioni Perl sfruttate da module-starter scrivono anche diversi test in più (per lo più inutili a mio avviso) ed un file ignore.txt che non ho capito ancora a cosa serve (*).

Quindi alla fine della fiera, buttando via la “fuffa” ci resta:

Module::Build crea Build.PL
Module::Install crea Makefile.PL
ExtUtils::MakeMaker crea Makefile.PL
h2xs crea Makefile.PL

Il Makefile.PL più stringato è quello di Module::Install (e ha una costruzione diversa), mentre i due Makefile.PL di h2xs e ExtUtils::MakeMaker sono praticamente identici (e si basano entrambi su WriteMakefile – anche h2xs usa ExtUtils::MakeMaker). Infine Build.PL ha il suo proprio modo per scriversi la configurazione, ma comunque pare abbastanza intuitivo.

I Makefile.PL di h2xs e EUMM sono virtualmente identici, e producono lo stesso risultato (un makefile che poi copia la lib in blib e generano le man page).

Il Makefile.PL di Module::Install genera un META.yml e una serie di file nella directory inc/ , infine il makefile che produce il solito output.

sim@idrogeno:/tmp/Test-Install$ perl Makefile.PL

include /tmp/Test-Install/inc/Module/Install.pm
include inc/Module/Install/Metadata.pm
include inc/Module/Install/Base.pm
include inc/Module/Install/Makefile.pm
include inc/Module/Install/AutoInstall.pm
include inc/Module/Install/Include.pm
include inc/Module/AutoInstall.pm
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies...
[Core Features]
- Test::More ...loaded. (0.98)
*** Module::AutoInstall configuration finished.
include inc/Module/Install/WriteAll.pm
include inc/Module/Install/Win32.pm
include inc/Module/Install/Can.pm
include inc/Module/Install/Fetch.pm
Checking if your kit is complete...
Looks good
Writing Makefile for Test::Install
Writing META.yml

Il file Build.PL di Module::Build genera un ulteriore script Build e delle configurazioni (json e yml); il tutto è gestito in Perl senza l’intervento di make e l’effetto è identico (./Build produce il solito blib/ ). La documentazione spiega un po’ meglio.

(*) Svelato l’arcano qui.

.cvsignore

Module::Starter assumes you’ll be using CVS for revision control, and provides a .cvsignore file with the names of files that are auto-generated and not to be tracked with revision control. At Perl Training Australia we use git for new projects, and so we rename this to .gitignore.

(As of version 1.52, this file is now called “ignores.txt”, so you can use it however you like.)

Coerce e DateTime::Format::ISO8601

Simotrone — Fri, 30 Sep 2011 05:58:00 +0000

In Moose (e sistemi derivati – Mouse) si può fissare un tipo di dato per attributo (isa).

has ‘points’   => ( isa => ‘Int’, is => ‘rw’, default => 0 );

# points deve essere (is a) un Int(ero)

Questo controllo può diventare rognoso se il tipo di attributo è complesso: ad esempio DateTime.

Può capitare di dover inserire nell’attributo un oggetto DateTime che rappresenta una data ed un tempo, ma come posso inserire il dato direttamente senza calcolare l’oggetto (ad esempio in lettura da un file)?
Qui entrano in gioco coerce, subtype, ecc.

subtype ‘My::DateTime’ => as ‘Object’ => where {$_->isa(‘DateTime’)};
has ‘datetime’ => (

        isa => ‘My::DateTime’, is => ‘rw’, required => 1,

        default => sub { DateTime->now() }

);

Questo attributo deve essere un DateTime (per l’esattezza un My::DateTime, ma questo serve solo per non inquinare i namespace in cui lavora Perl), ma vuole gli vengano passati solo oggetti DateTime.
Nel caso decidessi di passare un numero intero all’attributo datetime (es: $self->datetime(1)) intendendendo unix time l’isa genererebbe un errore; comportamento identico se passassi una stringa come “2004-09-16T23:59:58″.

Grazie alla proprietà coerce è possibile “costringere” un dato in entrata a traformarsi in DateTime anche se parte come qualcosa di diverso.

subtype ‘My::DateTime’ => as ‘Object’ => where {$_->isa(‘DateTime’)};
coerce ‘My::DateTime’

        => from ‘Num’ => via { DateTime->from_epoch( epoch => $_ ) } 

        => from ‘Str’ => via {

                my ($Y,$M,$D,$h,$m,$s) = uc($_) =~ m/^(\d{4})-(\d{2})-(\d{2})T(;

                return DateTime->new( year => $Y, month => $M, day => $D, hour ;

        };
has ‘datetime’ => (

        isa => ‘My::DateTime’, is => ‘rw’, required => 1,

        coerce => 1,

        default => sub { DateTime->now() }

);

In questo caso abbiamo definito due trasformazioni: in caso l’input sia un ‘Num’, esegui DateTime->from_epoch( epoch => $_ ); in caso sia una stringa passa il valore attraverso quella regex e ritorna un oggetto DateTime.

La cosa funzionava… poi mi è stato indicato DateTime::Format::ISO8601. Troppo bello.

subtype ‘My::DateTime’

        => as ‘Object’ => where {$_->isa(‘DateTime’)};

coerce ‘My::DateTime’

        => from ‘Num’ => via { DateTime->from_epoch(epoch => $_)}

        => from ‘Str’ => via { DateTime::Format::ISO8601->parse_datetime($_)};
has ‘datetime’ => (

        isa => ‘My::DateTime’, is => ‘rw’, required => 1,

        coerce => 1,

        default => sub { DateTime->now() }

);

Facile, sintetico… elegante.

HTTP::Message

Simotrone — Tue, 20 Sep 2011 05:31:44 +0000

Pistolando con LWP e qualche chiamata HTTP, avevo bisogno di rendermi conto che cosa mi stesse passando il server.

Ho trovato estremamente utile a scopo di debugging il metodo headers_as_string proprio della risposta (HTTP::Response) che lo eredita da HTTP::Message.

Direi che è l’equivalente del flag -e di lwp-request.

sim@idrogeno:~$ lwp-request -dsUe www.google.com

GET http://www.google.it/

User-Agent: lwp-request/5.827 libwww-perl/6.02
200 OK

Cache-Control: private, max-age=0

Connection: close

Date: Sun, 18 Sep 2011 13:39:47 GMT

Server: gws

Content-Type: text/html; charset=ISO-8859-1

Expires: -1

Client-Date: Sun, 18 Sep 2011 13:39:47 GMT

Client-Peer: 209.85.148.105:80

Client-Response-Num: 1

Set-Cookie: we_have_cookies; expires=Tue, 17-Sep-2013 13:39:47 GMT; path=/; domain=.google.it

Set-Cookie: we_have_a_lot_of_cookies!; expires=Mon, 19-Mar-2012 13:39:47 GMT; path=/; domain=.google.it; HttpOnly

Title: Google

X-XSS-Protection: 1; mode=block

Cool.

Stream parser e subclassing

Simotrone — Sat, 10 Sep 2011 05:25:28 +0000

Dovendo fare il parsing di un XML ho deciso di cambiare libreria e provare qualcosa di nuovo.

Fino ad ora ho sempre usato XML::LibXML che mette in memoria una mappa dell’XML e poi permette di navigarci dentro (DOM).

XML::Parser è uno stream parser che si basa su Expat: l’idea di Expat è avere un puntatore che scorre lungo lo stream xml e rileva eventi specifici (es: la presenza di un tag di apertura) a cui corrispondono delle funzioni che devono elaborare; a queste callback vengono passati determinati parametri (es: un’istanza del parser expat, l’elemento, gli attributi).

La mia implementazione in Perl era dentro un oggetto:

package Oggetto;

…

sub read {

        my $self = shift;

        my $input = $self->filepath;

        my $sb = $self->scoreboard;

        $parser = XML::Parser->new( Handlers => {

                Start => \&handle_start,

                End   => \&handle_end,

        });

        $parser->parse($input);

}

sub handle_start {

        my ( $parser, $element, %attributes ) = @_;

        # fai qualcosa…

}

…

e il mio problema principale era come passare un’istanza del mio oggetto alla funzione di callback in modo da avere gli attributi a disposizione della funzione stessa – nello specifico mi interessava avere $self->scoreboard che doveva essere popolato con gli elementi nell’xml.

Soluzione #1

Nello scope della funzione in cui coesistono sia l’istanza del parser che del mio oggetto (sub read {}) creare una sub anonima e passare il coderef all’opzione Handlers del parser.

sub read {

        my $self = shift;

        my $input = $self->filepath;

        my $sb = $self->scoreboard;

        my $handle_start = sub {

                my ( $parser, $element, %attributes ) = @_;

                # fai qualcosa…

                # qui dentro $self è vivo quindi $sb è raggiungibile

        };

        $parser = XML::Parser->new( Handlers => {

                Start => $handle_start

        });

        $parser->parse($input);

}

La cosa funziona ed è anche abbastanza chiara per i miei gusti, ma mi piaceva poco l’idea di avere una sub corposa scritta dentro un metodo… preferisco quando le sub anonime sono più brevi.

Soluzione #2 (Subclassing!)

Un’altro sistema può essere subclassare il parser e far sì che abbia a disposizione gli oggetti che mi servono ($sb).

Qui il trucco è subclassare non XML::Parser (che passa una istanza di Expat alla callback) ma XML::Parser::Expat stesso; nella copia locale scrivo due metodi per fare set and get di un attributo che il parser si porterà dietro in ogni sua istanza.

package Local::XML::Parser::Expat;

# subclassing

use base XML::Parser::Expat;

# set

sub set_current_object {

        my($self, obj) = @_;

        $self->{_current_object} = $obj;

}

# get

sub get_current_object {

        my($self) = @_;

        return $self->{_current_object};

}

1;

#

package Oggetto;

use Local::XML::Parser::Expat;

…

sub read {

        my $self = shift;

        my $input = $self->filepath;

        my $sb = $self->scoreboard;

        $parser = Local::XML::Parser::Expat->new( Handlers => {

                Start => \&handle_start,

                End   => \&handle_end,

        });

        $parser->set_current_object($sb); # set dell’attributo

        $parser->parse($input);

}

sub handle_start {

        my ( $parser, $element, %attributes ) = @_;

        # fai qualcosa…

        # e qui dentro è possibile fare

        # $parser->get_current_object()

        # per ottenere $sb 

}

…

Questa è una soluzione che mi piace molto ma richiede di complicare il progetto con un nuovo package che sostanzialmente non fa niente – inoltre richiede di scavalcare XML::Parser e usare direttamente Expat.

Soluzione #3

Un’altra soluzione è simile alla prima, ma con un passaggio in più nella sub anonima per tenere ordinate le cose.

sub read {

        my $self = shift;

        my $input = $self->filepath;

        my $sb = $self->scoreboard;

        $parser = XML::Parser->new( Handlers => {

                Start => sub { $self->_handle_start(@_) },

        });

        $parser->parse($input);

}

sub _handle_start {

        my ( $self, $parser, $element, %attributes ) = @_;

        # fai qualcosa…

        # qui dentro $self è vivo quindi $sb è raggiungibile

}

Questo sistema mi piace abbastanza: ha il vantaggio che la sub anonima è breve e c’è un riferimento chiaro ad un metodo interno all’oggetto.
L’unica cosa che mi piace pochino è il passaggio degli elementi nella sub anonima che a mio avviso è poco evidente, d’altra parte se dentro la sub anonima dovessi esplicitare

Handlers => {

        Start => sub {

                my ($parser, $elem, %attrs) = @_;

                $self->_handle_start( $parser, $elem, %attrs);

                # oppure la chiamata diretta ad una sub se si preferisce

                # _handle_start( $self, $parser, $elem, %attrs);

        },

}

perderei la brevità.

Ringraziamenti a larsen, dada, dakkar per il confronto a riguardo.