[Firenze-pm] ed adesso una domanda di perl: export

[Hakim Cassimally]

2009/3/30 Valerio Crini <vcrini at gmail.com>

> Salve nuovamente,
> adesso ho una domanda che mi torce lo stomaco in questi giorni.
> Ho un modulo perl con un sacco di subroutine e se voglio esportarle ho
> bisogno di elencarle tutte in @export. E' possibile fare in modo da non
> doverlo fare perchè
> le subroutine sono molte (mi servono per definire alcune costanti che
> ritornano stringhe) e di conseguenza mi tocca scrivere un @export enorme.
> Inoltre mi piacerebbe applicare il principio DRY (Don't Repeat Yourself)
> che lo so che è motlo rubyesco ma lo trovo molto logico e mi pare nua bella
> cosa seguirlo.
>
> insommo dato un modulo
>
> package Nonvoglioripetermi;
>
> sub sub1 {
> return "subroutine 1";
> }
> come faccio a non essere costretto a scrivere
>
> in testa al file @export= qw (sub1) ?


E' una domanda molto interessante.  Ci sono vari modi per farlo:

1) usare dei flag "questo e' esportabile" mentre definisci i sub.

Sfogliano CPAN, trovo per esempio Export::Lexical - non sono sicuro che era
quello a cui pensavo (quindi magari cerca ancora su search.cpan.org), cmq,
usando questo puoi fare

   sub sub1 : ExportLexical { ... }

e verra' esportato automaticamente.

2) fare una introspezione ai sub definiti.  Per esempio, usando
Class::Inspector::functions, puoi avere una lista di @function, da assegnare
ad @EXPORT (magari greppando i nomi prima).

3) usare un modulo exporter piu' sofisticato per fare l'esportaggio.  Per
esempio Sub::Exporter ti potrebbe permettere di dire

   "Creami i sub /pippo pluto pinco/ che saranno generati da un sub
\&make_constant"

(dove magari il make_constant restituera' valori tipo "PIPPO", "PLUTO",
"PINCO" a seconda del nome del sub, per dare un banalissimo esempio).

E' quest'approccio 3 che mi sembra forse quello piu' ragionevole.

4) Controllare se hai veramente bisogno di fare export di tanti constant.

Non conoscendo il codice tuo non potrei dare altri commenti... Pero' e'
possibile che a ristrutturare un po', non ci sarebbe bisogno.  Per esempio,
cambiando il modulo in una roba Object Oriented, ciascuno di questi constant
diventerebbe un semplice metodo del oggetto. ecc.ecc.
Se pasti un po' di altri dettagli si potrebbe considerare un po' altre
soluzioni,

Ciao,
osfameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/firenze-pm/attachments/20090331/66e787ed/attachment.html>