Odpowiedź.

Historia pytania:

W Perl przestrzeń nazw to główny sposób izolacji zmiennych i funkcji pomiędzy różnymi częściami programu. Dzięki dyrektywie package tworzone są niezależne obszary, z których każdy otrzymuje swój zestaw globalnych zmiennych i funkcji. Umożliwia to rozwijanie projektów wielofiltrowych bez konfliktów nazw.

Problem:

Niewłaściwe zarządzanie zakresem (scoping), mieszanie zmiennych leksykalnych i pakietowych, lub błędna praca z przestrzenią nazw "main" często prowadzi do problemów: pojawianie się nieoczekiwanych zmiennych, nadpisywanie funkcji, nieoczywiste błędy w podatkach i testach.

Rozwiązanie:

Każdy plik/moduł deklaruje swoją przestrzeń nazw za pomocą package SomeName;.
Zmienne leksykalne (my) są widoczne tylko w obrębie bloku, a globalne (our, wcześniej use vars) — w całym pakiecie.
Odwołanie do funkcji lub zmiennej innego pakietu: AnotherPackage::some_function().

Przykład kodu:

package MyApp::Utils;
our $global_var = 10;
sub do_something { return $global_var + 1; }

package main;
print MyApp::Utils::do_something(); # 11

Kluczowe cechy:

Wyraźne oddzielenie globalnej (package) i leksykalnej (my) przestrzeni.
Nazwa pakietu zawsze jest podawana jawnie przez :: w celu dostępu do obcych zasobów.
main — domyślna globalna przestrzeń nazw dla skryptów.

Pytania z podstępem.

Jaka jest różnica między my, our i local w pakietach?

my — zawsze tylko w bieżącym bloku leksykalnym.
our — deklaruje globalną zmienną pakietu, ale udostępnia ją jako leksykalne odniesienie w bloku.
local — tymczasowo nadpisuje globalną wartość zmiennej pakietu na czas trwania bloku.

Czy można wywołać funkcję bez wyraźnego wskazania pakietu?

Tak, jeśli funkcja jest eksportowana do bieżącego pakietu za pomocą modułu Exporter i use, w przeciwnym razie — tylko przez pełną nazwę.

Czy można zadeklarować kilka package w jednym pliku?

Tak, ale jest to trudne do zrozumienia — po każdym package wszystkie dalsze deklaracje odnoszą się do nowej przestrzeni nazw. Lepiej jest używać osobnych plików dla każdego pakietu.

Typowe błędy i antywzorce

Przypadkowe importowanie lub nadpisywanie zmiennych i funkcji z main w inne pakiety.
Używanie local zamiast my do deklaracji nowych zmiennych — prowadzi do niejawnych błędów.
Brak jawnej deklaracji package w module, co może prowadzić do mieszania nazw.

Przykłady z życia

Negatywny przypadek

W skrypcie zespołowym używano kilku package po sobie, w jednym pliku; zmienne były mylone, czasami leksykalne, czasami globalne.

Zalety:

Szybsze pisanie — cały kod w jednym pliku.

Wady:

Nieoczywiste błędy przy zmianie przestrzeni nazw, szczególnie dla globalnych zmiennych.
Trudno utrzymać i rozwijać.

Pozytywny przypadek

Każdy package przeniesiono do swojego osobnego modułu, funkcje eksportowano jawnie.