encapsulation des packages

Le
Edwin Vancleef
Chuis pas content :)

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 ?
Vos réponses
Trier par : date / pertinence
Nicolas George
Le #139089
Edwin Vancleef wrote in message
Comment empêcher cela ?


Pas d'autre moyen que de renommer l'un des deux.

Edwin Vancleef
Le #139088

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...


Paul Gaborit
Le #138344
À (at) 13 Feb 2007 16:53:53 GMT,
Edwin Vancleef

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 - Perl en français -


espie
Le #140576
In article Paul Gaborit
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
Le #140574
À (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 - Perl en français -
Publicité
Poster une réponse
Anonyme