Jak w Perl zrealizowane są modyfikatory dostępu do funkcji i zmiennych? Dlaczego w języku brakuje znanej z innych języków systemu public/private/protected, i jak w Perl ogranicza się dostęp do wewnętrznych danych modułów?

Odpowiedź.

W Perl brak klasycznego systemu modyfikatorów dostępu, jak public/private/protected. Cała kontrola dostępu do funkcji i danych odbywa się poprzez umowy i zakres widoczności zmiennych.

• Aby ograniczyć dostęp do zmiennych w module, używa się słowa kluczowego my (widoczność leksykalna w obrębie pliku lub bloku) oraz eksportuje symboli (za pomocą Exporter lub własnych mechanizmów).
• Podprogramy, które nie są eksportowane na zewnątrz (@EXPORT, @EXPORT_OK), domyślnie pozostają "wewnętrzne" dla modułu, chociaż w razie potrzeby zawsze można je jawnie wywołać z prefiksem pakietu.
• Wewnętrzne funkcje i zmienne zazwyczaj zaczynają się od znaku podkreślenia (_internal_sub), co stanowi umowę o prywatności.

Przykład:

package MyLib;
use Exporter 'import';
our @EXPORT_OK = qw(public_func);

my $secret = 123; # Niedostępny z zewnątrz

sub public_func {
    _internal_func();
}

sub _internal_func {
    print "To jest wewnętrzne!
";
}

1;

Pytanie z podstępem.

Jakie środki chronią prywatną funkcję modułu Perl przed wywołaniem z zewnątrz? Czy nie można jej wywołać bezpośrednio?

Odpowiedź: W rzeczywistości każdą podprogramę pakietu można wywołać jawnie pełną nazwą: MyLib::_internal_func(). Perl nie ogranicza tego wywołania technicznie — ochrona jest tylko na poziomie umowy.

Przykłady rzeczywistych błędów z powodu braku znajomości finezji tematu.

---

Historia

Programista wyeksportował zbyt wiele funkcji z modułu, zapominając o ograniczeniu przez @EXPORT_OK. W rezultacie użytkownicy przypadkowo uzyskali dostęp do wewnętrznych funkcji, co doprowadziło do konfliktów nazw i nieprawidłowego użycia API.

---

Historia

W dużym projekcie dwie zespoły korzystały z tej samej wewnętrznej metody (zaczynającej się od _), myśląc, że jest prywatna. Później zmieniono interfejs funkcji, co złamało wywołania z innej części systemu.

---

Historia

W jednym z projektów zmodyfikowano moduł zewnętrznego programisty, wywołując bezpośrednio jego nieeksportowane metody. Po aktualizacji dystrybucji moduł przestał działać, ponieważ wewnętrzne nazwy funkcji się zmieniły, co spowodowało awarię aplikacji.