Odpowiedź

W Perl obiekty to zazwyczaj referencje do hashy, a "sloty" (slots) to oddzielne pola hasha przechowujące dane obiektu. Aby zaoszczędzić kod i dynamicznie tworzyć metody, często używa się magicznej metody AUTOLOAD.

AUTOLOAD pozwala przechwytywać wywołania nieistniejących metod i dynamicznie je realizować "w locie". Przykład — autogeneracja metod-getterów i setterów:

package MyObj;
sub new { bless { foo => 1, bar => 2 }, shift }

our $AUTOLOAD;
sub AUTOLOAD {
    my ($self) = @_;
    my $field = $AUTOLOAD =~ s/.*:://r;
    die "Brak takiego slotu $field" unless exists $self->{$field};
    return $self->{$field};
}

my $obj = MyObj->new;
print $obj->foo;  # 1

Niebezpieczeństwa:

• Błędy nie są łapane w czasie kompilacji, a jedynie w czasie wykonania.
• Możliwe jest niekontrolowane dynamiczne tworzenie metod (autoloop)
• Przechwytywane są nawet literówki w nazwach metod, co utrudnia wykrywanie błędów.

Pytanie pułapka

Czym różni się AUTOLOAD od jawnego definiowania metody? Jakie są minusy używania AUTOLOAD dla wszystkich akcesorów klasy?

Odpowiedź: AUTOLOAD działa na etapie wykonania, w przeciwieństwie do jawnych metod. Zwykle błędy związane z nieprawidłową nazwą metody ujawniają się tylko w czasie wykonania, a nie podczas kompilacji, co utrudnia debugowanie. Przykład niewłaściwego użycia:

$obj->fop; # zamiast foo — nie spowoduje błędu kompilacji, trafi do AUTOLOAD

Lepiej jawnie generować metody przez eval w sekcji kompilowanej.

Przykłady rzeczywistych błędów z powodu nieznajomości niuansów tematu

---

Historia

W frameworku aplikacji webowej wszystkie metody-gettery zostały zaimplementowane przez AUTOLOAD w celu zmniejszenia duplikacji. Część programistów popełniała literówki w nazwach metod, które nie prowadziły do błędów podczas kompilacji lub uruchamiania, a po prostu zwracały undef, powodując nieprawidłowe działanie logiki biznesowej.

Historia

Projekt z dużą liczbą dynamicznych metod akcesorów urósł do takiego rozmiaru, że AUTOLOAD stał się "wąskim gardłem": znacznie spadła wydajność z powodu częstych wywołań AUTOLOAD i wydatku pamięci na tworzenie referencji kodowych "w locie".

Historia

W bibliotece do serializacji obiektów metody były automatycznie generowane przez AUTOLOAD, ale zapomniano zaimplementować specjalny DESTROY, w rezultacie przy usuwaniu obiektów uruchamiał się AUTOLOAD, pojawiały się błędy o braku metody DESTROY i wyciek pamięci.