Discussion :

[TheDrev]

Bonjour !
J'ouvre un file handler avec la fonction open pour la création de log. Comment faire pour que ce file hanler soit visible dans d'autres scripts .pl ?

J'ai bien penser a la passer en paramètres de fonction, mais cela ferai beaucoup de modifications et je préfère que ces fonctions s'occupent uniquement du traitement.

[Philou67430]

Il serait nettement plus "propre" de le passer en paramètre, mais si tu n'y tiens pas, tu peux fournir dans ton module qui créée le file handle, un accesseur qui le retourne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
open my $LOG, ">", "log.txt";
...
 
sub get_log_fh {
  return $LOG;
}

mieux : le module qui créée le file handle fourni également une fonction d'écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
sub printf_log {
  printf $LOG @_;
}
sub print_log {
  print $LOG @_;
}

[TheDrev]

en fait je n'utilise pas les modules pour le moment (je n'ai pas totalement compris comment cela se structure en perl), je suis tout en procédurale, avec un main.pl qui inclut quelques autres .pl...

J'ai essayé d'inclure main.pl depuis un autre script, mais le code est alors exécuté 2 fois !

Il faurdai que le handler soit ai une portée globale a tout les scripts... peut être qu'il faudra que je le vire du main.pl ?

[thierry.chich]

Raaaah mais c'est laid ! Blague à part, les modules ne sont pas très compliqués à élaborer, et offrir l'accès via une méthode particulière serait quand même un gagae de réussite du projet.

[Jasmine80]

Il faurdai que le handler soit ai une portée globale a tout les scripts

Peut-être peux-tu créer ton handle dans un script.pm puis l'appeler à partir de tous les autres scripts.

OpenFh.pm

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
package OpenFh;
 
use base 'Exporter';
 
our @EXPORT = qw($fh); # noms exportés par défaut
 
 
open our $fh, '<', 'chemin/fichier' or die $!;   # ouverture fichier
 
1;     # important, pour signaler que le module s'est bien chargé correctement

main.pl

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#!usr/bin/perl -w
 
use strict;
use warnings;
 
use OpenFh;
 
while (my $line = <$fh>){
	print $line;
}

Perldoc :Exporter

[Philou67430]

TheDrev, si tu n'utilises pas les modules, peux-tu nous expliquer comment tu fais inter-agir tes différents scripts actuellement ?

Comme dit thierry.chich, les modules (les plus simples, comme celui de Jasmine80) ne sont pas si compliqués, et sont quasiment la seule manière de concevoir une application perl réparties dans plusieurs sources différents (je connais encore "do", et c'est à peu près tout à ma connaissance).
Et tant qu'à utiliser un module, autant créer des accesseurs plutôt que de fournir un accès aux variables, afin de limiter les effets de bord.

[TheDrev]

j'utilise les fichiers comme je le ferai en c ou php par exemple. j'ai main.pl qui inclut avec require les autres scripts, et j'appelle les fonctions. Promis je vais regarder comment on fait avec les modules. Je croyait qu'on devait les utiliser pour faire de la POO...

[Philou67430]

Dans ce cas, tu n'as rien de particulier à faire, ton filehandle devrait être utilisable dans le module qui fait le require (sauf s'il est déclaré my).

[TheDrev]

je me documente sur les modules pour mieux apprécier vos exemple, merci !

[TheDrev]

Désolé pour l'attente, mais j'ai vraiment du me renseigner un minimum pour comprendre vos exemples. Pour résumer le probleme, faire un ensemble de scripts .pl et les importer avec require va executer le script. Les modules .pm qui sont inclue avec use permettent une inclusion comme avec une bibliothèque : portée des variables, etc (la POO étant une fonctionnalité ajouté ultérieurement et qui n'est pas obligatoire).

donc : il faut privilégier l'emploi des pm par rapport au pl ?

[Philou67430]

Tout dépend du besoin, mais à priori, si tu réalises des "fonctions" réutilisables, il est préférable de créer des modules .pm, éventuellement complétés de scripts .pl qui les utilisent.

[TheDrev]

merci, une toute dernière chose, pour créer un enum ou autre ensemble de define, lisible dans tout les scripts qui l'inclut, cela est possible avec les .pm et une portée definie avec our et exportée ?

[Philou67430]

Je ne suis pas sur de bien comprendre, mais je dirais oui : il est possible d'exporter des variables our depuis un module .pm (en utilisant Exporter).
Mais il serait préférable de fournir dans ce module, une fonction accesseur (une méthode si le module est utilisé en POO).

[TheDrev]

okey merci !

[Philou67430]

Au final, je trouve que la POO offre des tas d'avantages par rapport à la programmation fonctionnelle par module, car elle ne nécessite aucunement de se soucier de l'exportation des variables et fonctions, et les objets sont "auto-porteurs" du domaine des fonctions (espace de nom), ce qui est nettement plus parlant que des appels de fonctions simples après exportation.
Le seul point sensible est le constructeur, mais une fois que l'on s'est fait son modèle de constructeur, c'est un vrai plaisir.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
package MyClass;
 
sub new {
  my $class = shift;
 
  $class = ref($class) || $class; # if you plan to use $obj->new()
  my $self = { ... };
  ...
  return $self;
}
...

Et de ne pas oublier d'ajouter l'objet en premier paramètre de chaque méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  my $self = shift;

[Jedai]

Je pense qu'aujourd'hui, écrire directement ses objets n'est pas un bon choix, quoiqu'il soit toujours intéressant et utile de comprendre comment la POO fonctionne en sous-main en Perl.

Perl dispose aujourd'hui d'excellents modules pour créer facilement une hiérarchie objet cohérente, extensible et standard. Je conseille Moose et les modules associés (MooseX::Declare en particulier).

--
Jedaï

[Philou67430]

Ceci sera-t-il toujours valable avec perl6 ? (à savoir qu'il n'est pas conseillé de programmer directement ses objets)

[Jedai]

A vrai dire le système objet par défaut de Perl6 devrait ressembler pas mal à Moose (c'est plutôt l'inverse en fait, Moose s'est inspiré de Perl6) donc la question ne se pose pas trop.

Perl5 permet de programmer objet, mais le faire à la main est relativement ennuyeux et pas très intéressant (excepté pour comprendre comment ça marche en sous main, pour raisons pédagogiques), c'est pourquoi un certain nombre de modules proposent de simplifier et standardiser la procédure, Perl6 supportera de base un modèle objet standard proche de Moose, bien qu'il gardera une grande flexibilité du système sous jacent.

--
Jedaï

[djibril]

Il y a aussi son petit frère Coat qui fonctionne très bien et est purement Perl. Donc son installation est beaucoup simple dans divers environnements.

[Philou67430]

Merci Jedai pour ces précisions.

La question sous-jacente est alors : avec perl6, l'OOP sera-t-il intégré au langage, ou ce sera-t-il toujours une magie basée sur les principes de base de perl 5 (avec comme corolaire la nécessité de déclarer comme paramètre, l'objet dans les méthodes d'objet, la classe dans les méthodes de classe, et d'utiliser bless pour opérer la magie de conversion d'une référence en objet) ?