Ist es richtig, die globalen Variablen des Perl-Moduls direkt zu bekommen und speziell zu setzen?

Question

Ich frage mich, was die beste Praxis in Perl ist zu bekommen - oder, was noch wichtiger ist, setzen - eine globale Variable eines Moduls durch direkten Zugriff auf $Module::varName für den Fall, dass das Modul Getter/Setter-Methode dafür nicht zur Verfügung gestellt.

Der Grund, dass es mir schlecht riecht, ist die Tatsache, dass es die Kapselung irgendwie umgeht. Nur weil ich kann tun es in Perl, ich bin nicht ganz sicher, ich sollte (vorausgesetzt, es gibt tatsächlich eine Alternative wie Hinzufügen eines Getter/Setter zum Modul).

Answer 1

Die Kapselung wird nicht verletzt, wenn die Variable Teil der öffentlichen API ist. (Wenn es nicht das ist eine andere Sache.)

Ich denke, einen direkten Zugang ist vorzuziehen, da es Sie die Vorteile von dynamischen Scoping nehmen können:

local $Module::varName = 42; 

Dies macht Konflikte mit anderen Code Module weniger wahrscheinlich.

Answer 2

Globale Modulvariablen waren in der Vergangenheit in Mode, wurden aber in Modern Perl als "schlechte Form" angesehen. Es ist wichtig zu erkennen, dass Perl jetzt 22-23 Jahre alt ist und Stile und Praktiken sich geändert haben. :) Beachten Sie jedoch, dass es Zeiten gibt, in denen es immer noch angemessen ist, weil es einige sehr nette Features gibt, die mit Paketvariablen einhergehen. Es ist wie immer eine Frage der Erfahrung und Praxis zu sehen, was eine gute Lösung sein könnte.

Um die beste Verwendung für Paketvariablen zu verstehen, müssen Sie wirklich verstehen, wie local funktioniert. Schauen Sie sich local's perldoc help an. Mit Local können Sie eine Paketvariable wie (beispielsweise) $My::Variable im Paket My erstellen und eine dynamically scoped -Version davon erstellen. Normalerweise, wenn Sie $My::Variable an Ort und Stelle ändern, wird es sich auf Ihr gesamtes Programm auswirken und wird bestehen bleiben. Für kleine Programme ist das vielleicht keine große Sache. Für große kann dies katastrophale Nebenwirkungen haben. local können Sie eine temporäre Änderung an dieser Variable vornehmen, die auf Ihren aktuellen Bereich beschränkt ist.

Hier ist, wie es funktioniert:

use 5.012; 
use warnings; 

package My; 

our $Variable = 5; 

package main; 

say $My::Variable; # prints 5 
$My::Variable = 7; 
say $My::Variable; # prints 7 
{ # create a new lexical scope 
    local $My::Variable = 10; # create a new dynamic scope for $My::Variable 
           # that will persist to the end of the lexical scope 
    say $My::Variable; # prints 10 
} 
say $My::Variable; # end of the lexical scope for the localized 
        # $My::Variable, so prints 7 again 

Effektiv können Sie damit Paketvariablen in einer sicheren Weise. Leider weiß nicht jeder über local, so dass sie oft die globale Variable überlisten. Eine gute Dokumentation zu dokumentieren (zB local) hilft immer.

Ein Getter/Setter mit korrekter Objektkapselung verhindert viel, aber nicht immer. Damit es so funktioniert wie eine lokale Variable, müssten Sie viel zusätzliche Arbeit leisten. Das Schönste daran, eine Paketvariable lokalisieren zu können, ist, dass Sie temporäre Änderungen sehr einfach durchführen können, z. B. für eine Debug-Variable. Normalerweise müssen Sie wie ein Muster tun:

{ 
    my $current_variable My::get_variable(); 
    $My::set_variable($new_value); 

    # Do code work 

    $My::set_variable($current_variable); 
} 

mit lokalen, dies zu:

{ 
    local $My::Variable = $new_value; 

    # do code work 
} 

(Übrigens, ich wünsche Ihnen auch dies zu lexikalischen Variablen tun könnte, aus dem gleichen Grund .. .aber Sie können nicht.) Also, für einige Dinge, können Paketvariablen Sinn machen. Es hängt davon ab, wie Sie es verwenden möchten.Dinge wie

• Debugging Variablen
• globale Konfiguration, die nicht/nicht oft

jedoch geändert werden, der Fall ist, wenn es etwas, das in regelmäßigen Abständen geändert werden muss, wie

• verwendet regelmäßig Variablen (siehe die schreckliche Schnittstelle für File::Find)
• Temporäre Konfiguration
• „Objekt“ Variablen

Im Grunde alles, was mehr als einmal oder in seltenen Fällen geändert werden muss oder sollte auf andere Weise in ein erzeugten Objekt eingekapselt wird, dann würde ich das Paket vermeiden Variable.

Answer 3

Gibt es keine Eingabe-Hygiene/Fehlerbehandlung, worum es bei der Kapselung geht?

Wenn es keine Notwendigkeit für solche gibt, dann könnte man gegen die Implementierung von Getter und Setter argumentieren, die dann etwas albern wie sub set_variable { $variable = shift; } aussehen würde.

Wohlgemerkt, es ist einfacher für das Auge zu verwenden set_variable(42) als was Michael suggeriert!

Answer 4

Wenn das Modul keinen Accessor bietet, erstellen Sie einen, verwenden Sie ihn und senden Sie den Patch.