[Toulouse-pm] [ppm] my YAPC::Europe (Mercredi) (fwd)
Michel Rodriguez
mirod at xmltwig.com
Tue Jul 29 10:28:34 CDT 2003
Michel Rodriguez
Perl & XML
http://www.xmltwig.com
---------- Forwarded message ----------
Date: Tue, 29 Jul 2003 14:12:40 +0200
From: Arnaud Arhuman ASSAD <arnaud.assad at free.fr>
To: paris-pm-list at pm.org
Subject: [ppm] my YAPC::Europe (Mercredi)
Bonjour,
Comme prommis mon compte rendu (vous devez commencer à en avoir marre non ?)
Je peux continuer à parler des talks, mais peut être préférez vous entendre
parler du coté "social" (tout ce qui est pas talks quoi :-)
Arnaud.
***************************************************
Pour mon premier talk j'ai longtemps hésité...
Stas Beckman qui parle de mod_perl 2, Nicolas Clark qui explique comment
optimiser la vitesse de Perl et Dominus qui doit parler des itérateurs.
J'irai finalement écouter MJD, c'est pas tant le sujet (qui m'intéresse
quand même) que l'orateur qui fera pencher la balance...
MJD présente d'abord des itérateurs que nous utilisons constamment :
Les descripteurs de fichiers (FileHandle), les fonctions readdir et each
et enfin les objets DBI...
Il explique alors leur intérêt : Gain de mémoire. Possibilité de
reprendre un traitement sur un ensemble la ou on l'avait interrompu...
Il donne plusieurs exemples dont un assez impressionnant sur la génération
de séquence d'ADN et un sur le parcours de répertoire.
Il donne plusieurs exemples d'implémentation possible : closure, objet...
C'est bien beau tout ça, mais moi j'adore le traitement de liste, car
j'adore chaîner les map et les greps, qu'a cela ne tienne il nous sort
de son chapeau (en fait il l'a pas encore le fameux chapeau ;-) 'imap'
et 'igrep' les fonctions 'map' et 'grep' pour itérateurs. Il explique
ensuite comment en chaînant ces commandes on peut modifier simplement
le comportement du programme : en ajoutant des fonctionnalités avec
'imap' et en ajoutant des filtres avec 'igrep' Que dire ? C'est...beau !
Un truc que je note aussi sec en haut de ma TODO list !
Il évoque aussi le problème des semi-prédicats (des fonctions dont la
valeur fausse de Perl peut être dans les valeurs valides retournées)
évoque plusieurs solution dont celle de retourner une référence vers
la valeur (comme avec DBI) pour distinguer la valeur undef d'un retour
indéfini (pas de résultat) bizarrement il parle pas de la méthode
classique qui consiste à ne retourner qu'un code de retour (qui indique
uniquement le succès et l'échec de la fonction) et a retourner le résultat
par les paramètres (en passant une référence) a la façon du scanf du C.
MJD maîtrise visiblement son sujet, il est clair et distille ça et là
des astuces et des précisions techniques.
C'est l'heure de manger et je quitte la salle avec les doigts qui me
démangent (je veux coder !!!) et l'impression d'avoir passé une matinée
profitable.
<REPAS>
14h15 Je suis dans les starting blocks pour écouter MJD nous donner ses
tours de magicien... Il commence par mettre un chapeau (bizarre, sans
bord) nous expliquant que lorsqu'il donnait cette présentation au début,
il précisait qu'il n'était pas lui-même un magicien (Wizard). Mais qu'un
jour Larry lui a dit qu'il le considérait comme un de ses wizards, un
de ses hauts-elfes pour être précis (MJD lui se voyait plutôt en nain,
a concevoir ses chefs d'oeuvres dans son coin) et depuis : Il fait le talk
avec un chapeau de Magicien (et la il nous sort un beau chapeau pointu...)
La première partie pourrait s'intituler "Tout ce que vous avez voulu
savoir sur les globs et même plus..." C'est bourré d'astuces !
On apprend plus sur Exporter, ou comment faire des alias à passer des
descripteurs de fichiers (et surtout pourquoi il vaut mieux utiliser \*
pour ça...) ou faire des fonctions qui encapsulent d'autres fonctions
d'une manière transparente... Il nous présente les "Globjets" des
objets qui sont des glob consacrés. (Je me souviens plus très bien la
raison d'utiliser ces bestioles, je crois que le but est de disposer
d'un filehandle lié à l'objet...)
Suit une présentation d'AUTOLOAD, après la présentation des globs, on est
en terrain connu. Il présente encore plusieurs astuces comme gérer tous
les accesseurs des attributs d'un objet via une unique fonction AUTOLOAD
(Ça j'y vais déjà pensé par moi même...) puis comment on peut encore
améliorer la chose en utilisant la compilation dynamique (Et la y'a
qu'un wizard pour penser à un truc comme ça ;-)
je ne résiste pas au plaisir de vous montrer la chose :
sub AUTOLOAD {
# ... as before; set up $method ... my $code = q{
sub {
my ($self) = @_; my $val = $self->{METHODNAME};
$self->{METHODNAME} = shift if @_; $val;
}
}; $code =~ s/METHODNAME/$method/g; *$AUTOLOAD = eval $code;
goto &$AUTOLOAD;
}
Au passage il explique le "magic goto" ("goto &$AUTOLOAD") qui est au
return ce que exec est à system. (en fait lors d'un "magic goto" la
fonction appelée ne voit pas l'appelant intermédiaire (Rassurez vous
MJD explique ça beaucoup mieux ;-))
Puis il parle de source Filter : Il faut utiliser Filter::Simple car pour
une fois un module ::Simple est vraiment simple à utiliser, surtout par
rapport à Filter::Util::Call (Je confirme, je me suis un peu amusé avec
en écrivant Devel::StealthDebug, c'est simple et on peut faire des trucs
vraiment bizarre...) Il donne un exemple pour coder un source avec Rot13.
Il parle de tie (très bien expliqué dans "Programmation avancée en Perl",
soit dit en passant) il parle aussi de Next.pm un module étrange qui
analyse la hiérarchie d'héritage pour déterminer quelle fonction appeler
(Mais la j'avoue que j'ai un peu décroché).
Ce talk est en fait impossible a résumer : Il est dense,
plaisant, clair (a la différence de ce résumé ;-) et bourré de
détails/astuces/précisions techniques : Pourquoi %{$caller."::foo"}
est différent de %{"$caller::foo"} :-)
J'ai rien noté du talk suivant, mais il a été déjà bien décrit,
alors je serai bref.
* Les gars de la NASA ont envoyé un message inepte aux extra-terrestres
(avec des typos, des erreurs de représentation sur les ondes sonores...)
* MJD a séduit sa femme grace a un programme Perl (moi c'est grâce à
mon sex-appeal ;-)
* Promouvoir 'use strict' ne sert a rien si l'utilisateur ne comprend pas
use 'strict' Il fait à ce sujet une remarque assez intéressante sur le
fait que la raison la plus souvent invoquée pour promouvoir 'use strict'
est que ça encourage les bonnes pratiques de programmation, ce à quoi MJD
répond pensez vous vraiment que recopier dans son code des instructions
qu'on ne comprends pas soit une bonne pratique ? Il a raison le bougre...)
Note pour la prochaine yapc apprendre le touch-type ;-)
-
Paris Perl Mongueu(r|se)s => http://paris.mongueurs.net/mail.html
More information about the Toulouse-pm
mailing list