Lorsqu'on fait appel à un package X qui fait lui-même appel à un package Y, le
package Y est accessible à partir du programme appelant. Par exemple, je peux
faire appel à la fonction f du package Y dans le programme appelant :
Y::f( 3 );
...alors que le package Y n'est même pas déclaré (pas de "use Y"). J'aimerais
faire appel à un autre package Y (de même nom !), or, l'interpréteur confond le
package Y déclaré en X avec le nouveau package Y que je veux utiliser...
Comment empêcher cela ?
Ca fait peur... Il n'y a donc pas d'encapsulation de package ? Le pire, c'est que ça a l'air vrai :
use Data::Dumper; # ce package fait appel a Carp Carp::croak "salut"; # utilisation de Carp sans l'avoir declare
Ces 2 lignes marchent. Data::Dumper est un package de base, alors si les package de base n'encapsulent pas, c'est que ça ne doit pas être possible...
Pourtant, j'ai connu l'encapsulation dans tous les autres langages, et ça me paraissait être un bon principe...
Paul Gaborit
À (at) 13 Feb 2007 16:53:53 GMT, Edwin Vancleef écrivait (wrote):
Comment empêcher cela ?
Pas d'autre moyen que de renommer l'un des deux.
Ca fait peur... Il n'y a donc pas d'encapsulation de package ? Le pire, c'est que ça a l'air vrai :
use Data::Dumper; # ce package fait appel a Carp Carp::croak "salut"; # utilisation de Carp sans l'avoir declare
Ces 2 lignes marchent. Data::Dumper est un package de base, alors si les package de base n'encapsulent pas, c'est que ça ne doit pas être possible...
Pourtant, j'ai connu l'encapsulation dans tous les autres langages, et ça me paraissait être un bon principe...
Je ne sais pas ce que vous voulez dire par "encapsulation"... Mais à ma connaissance, tous les langages fonctionnent sur le même principe que Perl.
La seule différence entre Perl et les autres langages, c'est que la notion d'information privée n'existe pas. Si quelque chose existe, c'est pour tout le monde. La notion d'information privée n'est garantie que par un contrat moral entre le programmeur et les modules : "je n'utilise pas les variables ou fonctions dont le nom commencent par _", "les noms en majuscules sont des constantes (ou des filehandles)", "je ne pollue pas l'espace de nommage des autres en exportant n'importe quoi", etc. Libre au programmeur de respecter ou non ces conventions.
Pour l'exemple ci-dessous, l'utilisation de Carp en comptant sur Data::Dumper pour le charger, n'est pas respectueux de ce que propose Data::Dumper. Il vaut mieux faire le 'use Carp;' soi-même.
Mais quoi qu'il arrive le module dont le nom est 'Carp' est chargé.
Maintenant, c'est peut-être la notion de template (de C++, par exemple) que vous cherchez. C'est rarement utile en Perl mais ça peut se faire...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 13 Feb 2007 16:53:53 GMT,
Edwin Vancleef <e.vancleef@nospam.invalid> écrivait (wrote):
Comment empêcher cela ?
Pas d'autre moyen que de renommer l'un des deux.
Ca fait peur... Il n'y a donc pas d'encapsulation de package ? Le pire, c'est
que ça a l'air vrai :
use Data::Dumper; # ce package fait appel a Carp
Carp::croak "salut"; # utilisation de Carp sans l'avoir declare
Ces 2 lignes marchent. Data::Dumper est un package de base, alors si les
package de base n'encapsulent pas, c'est que ça ne doit pas être possible...
Pourtant, j'ai connu l'encapsulation dans tous les autres langages, et ça me
paraissait être un bon principe...
Je ne sais pas ce que vous voulez dire par "encapsulation"... Mais à
ma connaissance, tous les langages fonctionnent sur le même principe
que Perl.
La seule différence entre Perl et les autres langages, c'est que la
notion d'information privée n'existe pas. Si quelque chose existe,
c'est pour tout le monde. La notion d'information privée n'est
garantie que par un contrat moral entre le programmeur et les modules
: "je n'utilise pas les variables ou fonctions dont le nom commencent
par _", "les noms en majuscules sont des constantes (ou des
filehandles)", "je ne pollue pas l'espace de nommage des autres en
exportant n'importe quoi", etc. Libre au programmeur de respecter ou
non ces conventions.
Pour l'exemple ci-dessous, l'utilisation de Carp en comptant sur
Data::Dumper pour le charger, n'est pas respectueux de ce que propose
Data::Dumper. Il vaut mieux faire le 'use Carp;' soi-même.
Mais quoi qu'il arrive le module dont le nom est 'Carp' est chargé.
Maintenant, c'est peut-être la notion de template (de C++, par
exemple) que vous cherchez. C'est rarement utile en Perl mais ça peut
se faire...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 13 Feb 2007 16:53:53 GMT, Edwin Vancleef écrivait (wrote):
Comment empêcher cela ?
Pas d'autre moyen que de renommer l'un des deux.
Ca fait peur... Il n'y a donc pas d'encapsulation de package ? Le pire, c'est que ça a l'air vrai :
use Data::Dumper; # ce package fait appel a Carp Carp::croak "salut"; # utilisation de Carp sans l'avoir declare
Ces 2 lignes marchent. Data::Dumper est un package de base, alors si les package de base n'encapsulent pas, c'est que ça ne doit pas être possible...
Pourtant, j'ai connu l'encapsulation dans tous les autres langages, et ça me paraissait être un bon principe...
Je ne sais pas ce que vous voulez dire par "encapsulation"... Mais à ma connaissance, tous les langages fonctionnent sur le même principe que Perl.
La seule différence entre Perl et les autres langages, c'est que la notion d'information privée n'existe pas. Si quelque chose existe, c'est pour tout le monde. La notion d'information privée n'est garantie que par un contrat moral entre le programmeur et les modules : "je n'utilise pas les variables ou fonctions dont le nom commencent par _", "les noms en majuscules sont des constantes (ou des filehandles)", "je ne pollue pas l'espace de nommage des autres en exportant n'importe quoi", etc. Libre au programmeur de respecter ou non ces conventions.
Pour l'exemple ci-dessous, l'utilisation de Carp en comptant sur Data::Dumper pour le charger, n'est pas respectueux de ce que propose Data::Dumper. Il vaut mieux faire le 'use Carp;' soi-même.
Mais quoi qu'il arrive le module dont le nom est 'Carp' est chargé.
Maintenant, c'est peut-être la notion de template (de C++, par exemple) que vous cherchez. C'est rarement utile en Perl mais ça peut se faire...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
espie
In article , Paul Gaborit <Paul.Gaborit+ wrote:
La seule différence entre Perl et les autres langages, c'est que la notion d'information privée n'existe pas. Si quelque chose existe, c'est pour tout le monde. La notion d'information privée n'est garantie que par un contrat moral entre le programmeur et les modules : "je n'utilise pas les variables ou fonctions dont le nom commencent par _", "les noms en majuscules sont des constantes (ou des filehandles)", "je ne pollue pas l'espace de nommage des autres en exportant n'importe quoi", etc. Libre au programmeur de respecter ou non ces conventions.
Si, quand meme un peu.
Les variables lexicales declarees avec my sont quand meme un peu difficiles a atteindre de l'exterieure.
D'aucuns s'en servent pour les `inside-out' objects d'ailleurs (confere par exemple Class::InsideOut), avec la construction: my $obj = (my $scalar); pour fabriquer des ref sur des scalaires anonymes.
J'avoue que je ne suis pas fan, et que je prefere la philosophie classique de perl, mais c'est quand meme faisable, meme si c'est un tantinet retord...
In article <wt9ejodtidj.fsf@vaugirard.enstimac.fr>,
Paul Gaborit <Paul.Gaborit+news@enstimac.fr> wrote:
La seule différence entre Perl et les autres langages, c'est que la
notion d'information privée n'existe pas. Si quelque chose existe,
c'est pour tout le monde. La notion d'information privée n'est
garantie que par un contrat moral entre le programmeur et les modules
: "je n'utilise pas les variables ou fonctions dont le nom commencent
par _", "les noms en majuscules sont des constantes (ou des
filehandles)", "je ne pollue pas l'espace de nommage des autres en
exportant n'importe quoi", etc. Libre au programmeur de respecter ou
non ces conventions.
Si, quand meme un peu.
Les variables lexicales declarees avec my sont quand meme un peu difficiles
a atteindre de l'exterieure.
D'aucuns s'en servent pour les `inside-out' objects d'ailleurs (confere par
exemple Class::InsideOut), avec la construction:
my $obj = (my $scalar);
pour fabriquer des ref sur des scalaires anonymes.
J'avoue que je ne suis pas fan, et que je prefere la philosophie classique
de perl, mais c'est quand meme faisable, meme si c'est un tantinet retord...
La seule différence entre Perl et les autres langages, c'est que la notion d'information privée n'existe pas. Si quelque chose existe, c'est pour tout le monde. La notion d'information privée n'est garantie que par un contrat moral entre le programmeur et les modules : "je n'utilise pas les variables ou fonctions dont le nom commencent par _", "les noms en majuscules sont des constantes (ou des filehandles)", "je ne pollue pas l'espace de nommage des autres en exportant n'importe quoi", etc. Libre au programmeur de respecter ou non ces conventions.
Si, quand meme un peu.
Les variables lexicales declarees avec my sont quand meme un peu difficiles a atteindre de l'exterieure.
D'aucuns s'en servent pour les `inside-out' objects d'ailleurs (confere par exemple Class::InsideOut), avec la construction: my $obj = (my $scalar); pour fabriquer des ref sur des scalaires anonymes.
J'avoue que je ne suis pas fan, et que je prefere la philosophie classique de perl, mais c'est quand meme faisable, meme si c'est un tantinet retord...
Paul Gaborit
À (at) Mon, 26 Feb 2007 12:45:27 +0000 (UTC), (Marc Espie) écrivait (wrote):
Si, quand meme un peu.
Les variables lexicales declarees avec my sont quand meme un peu difficiles a atteindre de l'exterieure.
D'aucuns s'en servent pour les `inside-out' objects d'ailleurs (confere par exemple Class::InsideOut), avec la construction: my $obj = (my $scalar); pour fabriquer des ref sur des scalaires anonymes.
J'avoue que je ne suis pas fan, et que je prefere la philosophie classique de perl, mais c'est quand meme faisable, meme si c'est un tantinet retord...
Justement, les variables lexicales ne rentrent pas en ligne de compte dans la gestion des espaces de nommages puisque c'est un mécanisme lexicale indépendant. On ne peut pas cacher (facilement) un package ou le nommer avec un autre nom (sauf à passer par des filtres lors de la compilation... et encore).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 26 Feb 2007 12:45:27 +0000 (UTC),
espie@lain.home (Marc Espie) écrivait (wrote):
Si, quand meme un peu.
Les variables lexicales declarees avec my sont quand meme un peu difficiles
a atteindre de l'exterieure.
D'aucuns s'en servent pour les `inside-out' objects d'ailleurs (confere par
exemple Class::InsideOut), avec la construction:
my $obj = (my $scalar);
pour fabriquer des ref sur des scalaires anonymes.
J'avoue que je ne suis pas fan, et que je prefere la philosophie classique
de perl, mais c'est quand meme faisable, meme si c'est un tantinet retord...
Justement, les variables lexicales ne rentrent pas en ligne de compte
dans la gestion des espaces de nommages puisque c'est un mécanisme
lexicale indépendant. On ne peut pas cacher (facilement) un package ou
le nommer avec un autre nom (sauf à passer par des filtres lors de la
compilation... et encore).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 26 Feb 2007 12:45:27 +0000 (UTC), (Marc Espie) écrivait (wrote):
Si, quand meme un peu.
Les variables lexicales declarees avec my sont quand meme un peu difficiles a atteindre de l'exterieure.
D'aucuns s'en servent pour les `inside-out' objects d'ailleurs (confere par exemple Class::InsideOut), avec la construction: my $obj = (my $scalar); pour fabriquer des ref sur des scalaires anonymes.
J'avoue que je ne suis pas fan, et que je prefere la philosophie classique de perl, mais c'est quand meme faisable, meme si c'est un tantinet retord...
Justement, les variables lexicales ne rentrent pas en ligne de compte dans la gestion des espaces de nommages puisque c'est un mécanisme lexicale indépendant. On ne peut pas cacher (facilement) un package ou le nommer avec un autre nom (sauf à passer par des filtres lors de la compilation... et encore).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
