la difficulté de maintenance de perl est de l'ordre de la difficulté de la maintenance d'un manuel de feuille d'impots ou un livre a auteurs multiples.
dans la programmation classique, on instaure des coding-rules plus ou moins stupide qu'il faut changer regulierement car l'on se rend compte des soucis qu'ils produisent. au hasard, je cite la notation hongroise massivement utilisé par MS qui si l'on en a pas l'habitude est illisible.
le probleme de la maintenabilité de perl se situe à l'opposé de cela : perl se lisant à voix haute ( tu as rappelé que Larry Wall est linguiste ), ne peut se maintenir que si l'on se relis ...
... à voix haute
... comme pour faire de la poésie, savoir si ca sonne bien ( de toute facon, on sait qu'a la base l'interpreteur va se debrouiller pour l'interpreter plus ou moins comme on le souhaite ).
ton exemple de unless est tres bon, si tu n'as pas l'habitude, c'est clair que perl est hautement deroutant ( surtout si tu relis du code de personne qui font du C/Java&consort en perl )
do something() unless $my_case->is_empty();
do something() if ! $my_case->is_empty();
something() if ! $my_case->is_empty();
if ( ! $my_case->is_empty() ) {
something();
}
unless ( $my_case->is_empty() ) {
something();
}
Toutes ses propositions sont equivalentes. bizarrement, un non informaticien comprend la premiere. la seconde et la derniere sont limite.
mets en oeuvre mon conseil de lire le code a un beotien en programmation, et regarde si il comprend. je ne vais pas te rappeler que nous l'avons tous été, et que l'on a commencé avec des grandes phrases et des dessins. perl permet les grandes phrases.
Jouant avec la theorie des graphes les bases de données et perl depuis une dizaine d'années, je dois dire que perl m'a fait gagné enormement de temps pour coder et debugger du code. le seul equivalent est C mais il est trop couteux au niveau temps de developpement ( sauf pour des XS et Inline::* ) .
Pour ce qui est de mon bout de code, tu y es presque : si tu precise un HA::Net::SMTP tout court tu choisi celui par defaut, si tu choisi un rfc821 et que tu fais un ehlo() tu deviens rfc2821, et si tu fais un helo() en 2821 tu deviens rfc821 . bien entendu si tu forces un HA::Net::SMTP, et que tu fais un ehlo() et helo(), tu deviens la bonne classe.
ce que tu nommes un side effect n'en est pas un. j'utilise la meme chose en Java mais avec l'introspection ( lang.reflect.* ) et c'est ultra gore.
un autre grand interet est :
while ( my $packet = $socket->get_packet() ) {
next unless $packet->is_known();
$packet->handle();
}
ou get_packet() est un wrapper sur un constructeur de packet qui lui meme instancie une bonne classe fille ou reste un packet. packet::is_known retourne undef tandis que packet::*::is_known retourne @_.
apres, chaque packet::* a son propre handle() qui fait ce qu'il doit faire.
une subtilité au niveau lisibilité non-informaticienne est :
$_->handle() while $_ = $socket->gives_packet();
ou sur le principe precedent :
while ( my $packet = $socket->get_packet() ) { $packet->handle() }
qui se lit on execute le handle sur le paquet en cours tant qu'il y en a un fourni par la socket ( avec un handle() par defaut à nop comme tu as pu le deviner ;) ).
[^] # Re: Heu, perl ?
Posté par Mouns . En réponse au message Qui m'aime me suive !!. Évalué à 2.
dans la programmation classique, on instaure des coding-rules plus ou moins stupide qu'il faut changer regulierement car l'on se rend compte des soucis qu'ils produisent. au hasard, je cite la notation hongroise massivement utilisé par MS qui si l'on en a pas l'habitude est illisible.
le probleme de la maintenabilité de perl se situe à l'opposé de cela : perl se lisant à voix haute ( tu as rappelé que Larry Wall est linguiste ), ne peut se maintenir que si l'on se relis ...
... à voix haute
... comme pour faire de la poésie, savoir si ca sonne bien ( de toute facon, on sait qu'a la base l'interpreteur va se debrouiller pour l'interpreter plus ou moins comme on le souhaite ).
ton exemple de unless est tres bon, si tu n'as pas l'habitude, c'est clair que perl est hautement deroutant ( surtout si tu relis du code de personne qui font du C/Java&consort en perl )
do something() unless $my_case->is_empty();
do something() if ! $my_case->is_empty();
something() if ! $my_case->is_empty();
if ( ! $my_case->is_empty() ) {
something();
}
unless ( $my_case->is_empty() ) {
something();
}
Toutes ses propositions sont equivalentes. bizarrement, un non informaticien comprend la premiere. la seconde et la derniere sont limite.
mets en oeuvre mon conseil de lire le code a un beotien en programmation, et regarde si il comprend. je ne vais pas te rappeler que nous l'avons tous été, et que l'on a commencé avec des grandes phrases et des dessins. perl permet les grandes phrases.
Jouant avec la theorie des graphes les bases de données et perl depuis une dizaine d'années, je dois dire que perl m'a fait gagné enormement de temps pour coder et debugger du code. le seul equivalent est C mais il est trop couteux au niveau temps de developpement ( sauf pour des XS et Inline::* ) .
Pour ce qui est de mon bout de code, tu y es presque : si tu precise un HA::Net::SMTP tout court tu choisi celui par defaut, si tu choisi un rfc821 et que tu fais un ehlo() tu deviens rfc2821, et si tu fais un helo() en 2821 tu deviens rfc821 . bien entendu si tu forces un HA::Net::SMTP, et que tu fais un ehlo() et helo(), tu deviens la bonne classe.
ce que tu nommes un side effect n'en est pas un. j'utilise la meme chose en Java mais avec l'introspection ( lang.reflect.* ) et c'est ultra gore.
un autre grand interet est :
while ( my $packet = $socket->get_packet() ) {
next unless $packet->is_known();
$packet->handle();
}
ou get_packet() est un wrapper sur un constructeur de packet qui lui meme instancie une bonne classe fille ou reste un packet. packet::is_known retourne undef tandis que packet::*::is_known retourne @_.
apres, chaque packet::* a son propre handle() qui fait ce qu'il doit faire.
cela evite le :
while( my $packet = $socket->get_packet() ) {
if ( $packet->{type} eq "machin" ) {
# ...
} elsif ( $packet->{type} eq "bidule ) {
#...
} else {
}
}
une subtilité au niveau lisibilité non-informaticienne est :
$_->handle() while $_ = $socket->gives_packet();
ou sur le principe precedent :
while ( my $packet = $socket->get_packet() ) { $packet->handle() }
qui se lit on execute le handle sur le paquet en cours tant qu'il y en a un fourni par la socket ( avec un handle() par defaut à nop comme tu as pu le deviner ;) ).