Odpowiedź.

Historia pytania:

Perl od samego początku swojej ewolucji kładł duży nacisk na pracę z tablicami i listami danych. Takie funkcje jak map, grep oraz operator pętli foreach umożliwiają programistom zwięzłe i efektywne przetwarzanie kolekcji, realizując potężne wzorce programowania funkcyjnego w jednym wyrażeniu.

Problem:

Wielu początkujących programistów Perl myli sytuacje, kiedy należy użyć map, a kiedy foreach lub grep, co prowadzi do niewłaściwego wyboru narzędzia i obniżenia wydajności lub czytelności kodu. Ponadto, brak uwagi na efekty uboczne (side effects) w ciele takich wyrażeń prowadzi do trudnych do debugowania błędów.

Rozwiązanie:

Odpowiedni wybór środka do iteracji danych zależy od zadania:

map — używa się do przekształcania elementów listy i budowania nowej listy wynikowej.
grep — filtruje elementy źródłowej listy według podanego warunku.
foreach — używa się do efektów ubocznych i cyklicznego przetwarzania, częściej bez wartości zwracanej.

Przykład kodu:

my @numbers = (1, 2, 3, 4, 5);
my @squares = map { $_ * $_ } @numbers;                # [1, 4, 9, 16, 25]
my @even = grep { $_ % 2 == 0 } @numbers;              # [2, 4]
foreach my $n (@numbers) {
    print "Liczba: $n
";                              # wyświetla każdy element
}

Kluczowe cechy:

Funkcje map i grep działają w kontekście listy i zwracają nową listę.
foreach nie tworzy nowej listy, a jedynie iteruje po elementach.
Efekty uboczne w ciele map lub grep nie są zalecane.

Pytania z pułapką.

Czy można bezpiecznie modyfikować tablicę wewnątrz ciała map lub grep?

Nie, ponieważ Perl przechodzi przez listę kopii elementów, ale modyfikacja oryginalnej tablicy może prowadzić do nieoczekiwanych wyników lub nawet do nieskończonej pętli.

Co się stanie, jeśli użyjesz return w ciele map lub grep?

Wyrażenie return wewnątrz anonimnego bloku spowoduje wyjście z otaczającej subprogramu, a nie tylko z ciała map/grep, co jest niebezpieczne dla logiki programu.

Przykład kodu:

sub example {
    my @data = (1, 2, 0, 4);
    my @result = map { return "oops" if $_ == 0; $_+1 } @data; # wychodzi z example przy 0
}

Dlaczego nie można używać map tylko dla efektów ubocznych?

Ponieważ map jest przeznaczony do generowania nowych list, a wszystkie jego elementy są obliczane od razu. Dla efektów ubocznych bardziej optymalne jest użycie foreach — jest to bardziej czytelne i nie wymaga przechowywania wyniku.

Typowe błędy i anti-wzorce

Używanie map lub grep tylko z powodu efektów ubocznych.
Modyfikowanie struktury danych źródłowych wewnątrz map lub grep.
Nieprawidłowe przetwarzanie return w bloku.

Przykład z życia

Negatywny przypadek

W projekcie używano map do zapisu w logu, nawet nie interesując się zwracanym listą.

Zalety:

Zwięzły i "funkcjonalny" kod.

Wady:

Nadmierne zużycie pamięci.
Nie ma sensu w zwracanych wartościach, kod jest trudniejszy do zrozumienia.

Pozytywny przypadek

Użyto foreach do zapisu w logu, a map — tylko do generowania nowych list, nie mieszając wzorców.