201 votes

Quelle est la différence entre "my" et "our" en Perl ?

Je sais ce que my est en Perl. Il définit une variable qui n'existe que dans la portée du bloc dans lequel elle est définie. Qu'est-ce que our faire ?

Comment les our diffèrent de my ?

231voto

Fran Corpier Points 1513

Comment les our diffèrent de my et ce que fait our faire ?

En résumé :

Disponible depuis Perl 5, my est un moyen de déclarer des variables qui ne sont pas des paquets, c'est-à-dire :

  • privé
  • nouveau
  • non global
  • séparé de tout paquet, de sorte que la variable ne peut pas sont accessibles sous la forme de $package_name::variable .

D'autre part, our sont des variables de paquetage, et donc automatiquement :

  • mondial variables
  • définitivement non privé
  • pas nécessairement nouveau
  • peut sont accessibles en dehors du paquetage (ou de la portée lexicale) avec l'option avec l'espace de noms qualifié, comme $package_name::variable .

Déclarer une variable avec our vous permet de prédéclarer des variables afin de les utiliser sous use strict sans recevoir d'avertissement de faute de frappe ou d'erreur de compilation. Depuis Perl 5.6, il a remplacé l'obsolète use vars qui n'avait qu'une portée de fichier, et non une portée lexicale comme c'est le cas. our .

Par exemple, le nom formel et qualifié de la variable $x à l'intérieur package main es $main::x . Déclarer our $x vous permet d'utiliser le $x sans pénalité (c'est-à-dire sans erreur), dans la portée de la déclaration, lorsque le script utilise la variable use strict ou use strict "vars" . Le champ d'application peut être un, deux ou plusieurs paquets, ou un petit bloc.

2 votes

En quoi le nôtre diffère-t-il du local ?

19 votes

@Nathan Fellman, local ne crée pas de variables. Il n'est pas lié à my et our du tout. local sauvegarde temporairement la valeur de la variable et efface sa valeur actuelle.

2 votes

our ne sont pas des variables de paquetage. Ce ne sont pas des variables à portée globale, mais des variables à portée lexicale, tout comme my variables. Vous pouvez le constater dans le programme suivant : package Foo; our $x = 123; package Bar; say $x; . Si vous voulez "déclarer" une variable de paquetage, vous devez utiliser use vars qw( $x ); . our $x; déclare une variable à portée lexicale qui est aliasée à la variable du même nom dans le paquetage dans lequel la variable our a été compilée.

65voto

bubaker Points 1680

Les liens PerlMonks et PerlDoc de cartman et Olafur constituent une excellente référence - voici ma tentative de résumé :

my sont lexicalement cadrées à l'intérieur d'un seul bloc défini par {} ou dans le même fichier s'il n'est pas dans {} s. Ils ne sont pas accessibles à partir de paquets/sous-programmes définis en dehors de la même portée lexicale/du même bloc.

our Les variables sont délimitées au sein d'un paquet/fichier et accessibles à partir de n'importe quel code qui use ou require que les conflits de noms de paquets/fichiers sont résolus entre les paquets en ajoutant l'espace de noms approprié.

Pour compléter le tout, local sont "dynamiquement" cadrées, à la différence des variables my en ce sens qu'elles sont également accessibles à partir de sous-programmes appelés dans le même bloc.

2 votes

+1 pour " my sont lexicalement cadrées [...] à l'intérieur du même fichier si elles ne sont pas en {} s". Cela m'a été utile, merci.

50voto

FMc Points 22663

Un exemple :

use strict;

for (1 .. 2){
    # Both variables are lexically scoped to the block.
    our ($o);  # Belongs to 'main' package.
    my  ($m);  # Does not belong to a package.

    # The variables differ with respect to newness.
    $o ++;
    $m ++;
    print __PACKAGE__, " >> o=$o m=$m\n";  # $m is always 1.

    # The package has changed, but we still have direct,
    # unqualified access to both variables, because the
    # lexical scope has not changed.
    package Fubb;
    print __PACKAGE__, " >> o=$o m=$m\n";
}

# The our() and my() variables differ with respect to privacy.
# We can still access the variable declared with our(), provided
# that we fully qualify its name, but the variable declared
# with my() is unavailable.
print __PACKAGE__, " >> main::o=$main::o\n";  # 2
print __PACKAGE__, " >> main::m=$main::m\n";  # Undefined.

# Attempts to access the variables directly won't compile.
# print __PACKAGE__, " >> o=$o\n";
# print __PACKAGE__, " >> m=$m\n";

# Variables declared with use vars() are like those declared
# with our(): belong to a package; not private; and not new.
# However, their scoping is package-based rather than lexical.
for (1 .. 9){
    use vars qw($uv);
    $uv ++;
}

# Even though we are outside the lexical scope where the
# use vars() variable was declared, we have direct access
# because the package has not changed.
print __PACKAGE__, " >> uv=$uv\n";

# And we can access it from another package.
package Bubb;
print __PACKAGE__, " >> main::uv=$main::uv\n";

11voto

daotoad Points 17916

Faire face à la délimitation du champ de l'enquête est une bonne vue d'ensemble des règles de cadrage de Perl. Il est suffisamment ancien pour que our n'est pas abordée dans le corps du texte. Elle est abordée dans le Notes à la fin.

L'article parle des variables de paquetage et de la portée dynamique, et de la différence avec les variables lexicales et la portée lexicale.

5voto

ismail Points 19146

my est utilisé pour les variables locales, tandis que our est utilisé pour les variables globales.

Pour en savoir plus, consultez le site _Le cadrage des variables en Perl : les bases_ .

17 votes

Soyez prudent lorsque vous utilisez les mots local et global. Les termes appropriés sont lexical et package. Vous ne pouvez pas créer de véritables variables globales en Perl, mais certaines existent déjà, comme $_, et local fait référence à des variables de paquetage avec des valeurs localisées (créées par local), et non à des variables lexicales (créées avec my).

0 votes

${^Potato} est mondiale. Il fait référence à la même variable quel que soit l'endroit où vous l'utilisez.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X