Dlaczego domyślne zachowanie zakresu w Perlu jest takie, jakie jest?

Dec 10 2020

Uczę się Perla w szkole i obecnie uczę się o używaniu mysłowa kluczowego i określaniu zakresu w Perlu. (Dla porównania, zastanawiałem się, jak używać słowa kluczowego „moje” w Perlu? ). Mam nadzieję, że to pytanie nie zostało zadane gdzie indziej, ale jeśli nie ... dlaczego domyślne zachowanie Perla jest takie, jakie jest?

Wydaje mi się, że domyślny zakres w stylu C ma największy sens ... deklarujesz zmienną wewnątrz bloku, zmienna istnieje w tym bloku, a kiedy opuścisz ten blok, ta zmienna nie jest już dostępna. Dlaczego w Perlu, aby określić to zachowanie, musisz użyć mysłowa kluczowego? Wydaje się, że ograniczenie zakresu zmiennej tylko do miejsca, w którym jest używana, byłoby dobrym standardowym zachowaniem, a używanie przez mycały czas wydaje się być bardzo zbędne i przyczyniłoby się do zaśmiecania kodu.

Wydaje się, że to trochę jak wejście do sklepu spożywczego i natychmiastowe głośne zadeklarowanie preferowanej marki takiej a takiej przed kontynuowaniem zakupów, na wypadek gdyby ktoś wokół ciebie był zaciekawiony (a prawdopodobnie nie był).

(Potencjalny duplikat, to pytanie może zostać usunięte ... Po co deklarować zmienną Perla jako „mój” w zakresie pliku? ).

Odpowiedzi

9 ikegami Dec 10 2020 at 06:30

Jeśli potrzebujesz zmiennych o zasięgu leksykalnym, potrzebujesz jakiejś formy deklaracji. ^[1]

Wydaje mi się, że domyślny zakres w stylu C ma największy sens ... deklarujesz zmienną wewnątrz bloku, zmienna istnieje w tym bloku, a kiedy opuścisz ten blok, ta zmienna nie jest już dostępna

To dokładnie jak to działa w Perlu. Tam, gdzie deklarowałoby się zmienną int iw C, używa się my $iw Perlu. Oba tworzą zmienną o zasięgu leksykalnym, czyli zmienną, która jest widoczna tylko w bieżącym bloku i blokach zawartych. Podczas wykonywania kodu poza blokiem zmienna nie jest dostępna. Zakres zmiennych w Perlu jest taki sam, jak zakres zmiennych w C. ^[2]

// Can't use `i` here.           # Can't use `$i` here.
{                                {
   // Can't use `i` here.           # Can't use `$i` here. int i = 4; my $i = 4;
   printf("%d\n", i);       4       say $i; { { printf("%d\n", i); 4 say $i;
      int i = 5;                       my $i = 5; printf("%d\n", i); 5 say $i;
   }                                }
   printf("%d\n", i);       4       say $i; } } // Can't use `i` here. # Can't use `$i` here.

Python nie ma jawnych deklaracji zmiennych, ale nie ma też zmiennych o zasięgu leksykalnym; Zmienne Pythona mają zakres funkcji.
Jednak czas życia zmiennych nie jest taki sam. Skalar może pozostać żywy poza końcem bloku, w którym znajduje się w Perlu, ale tak nie jest w przypadku podobnych zmiennych w C (zmienne z „automatycznym czasem przechowywania”).

Na przykład,
```
# You can't use `@a` outside of the sub,
# But you can use the created array anonymously.
sub f { my @a = qw( abc def ); return \@a; }
```
W tym sensie my $xbardziej przypomina dynamicznie alokowaną strukturę.

6 Schwern Dec 10 2020 at 07:00

Ponieważ tak zrobił to Larry Wall w 1987 roku, a Perl 5 pozostaje wstecznie zgodny z tą decyzją. Zmienne leksykalne zostały wprowadzone dopiero w Perlu 5 w 1994 roku, a do tego czasu istniała dość duża baza instalacyjna programów w Perlu 4.

Spekuluję, dlaczego. Perl nie został pomyślany jako język aplikacji, stał się nim. Perl 1 został napisany w 1987 roku jako potężniejsza alternatywa dla sed , awk i powłoki Bourne'a .

Jeśli masz problem, który normalnie używałby sed, awk lub sh, ale przekracza ich możliwości lub musi działać trochę szybciej, a nie chcesz pisać głupich rzeczy w C, to perl może być dla ciebie.

Z podręcznika Perla 1.0 .

Programy sed i awk to zwykle jedna linia. W powłoce zmienne są globalne. Biorąc pod uwagę cel Perla 1, to było w porządku.

Zaakceptowane standardy inżynierii oprogramowania bardzo się zmieniły w ciągu ostatnich kilku dekad. Kiedy systemy były mniejsze i prostsze, zmienne globalne były bardziej akceptowalne. Wraz ze wzrostem złożoności zmienne globalne stanowią coraz większe zagrożenie.

1 lordadmira Dec 12 2020 at 11:15

Ściśle mówiąc, domyślnym zakresem zmiennych w Perlu jest pakiet globalny. Zmienne , które nie muszą być deklarowane . To dużo mówi o filozofii Perla. Jest zorientowany na zadania i wyróżnia się szybkim prototypowaniem oraz szybkim i brudnym programowaniem. Możesz pisać kompletne programy w wierszu poleceń, aby wykonywać raczej złożone zadania ( perl -e). Tylko masochista zrobiłby to perl -e 'use strict; ...'. Po prostu piszesz zmienne, a one po prostu działają. Jedną z tych filozofii jest DWIM - rób co mam na myśli. To całkowite przeciwieństwo większości „twardych” języków programowania, w których musisz zdefiniować świat, zanim będziesz mógł cokolwiek zrobić.

Następnie w odpowiednim czasie Larry'ego dostaliśmy strict, use vars, my, our, i state, aby zakończyć zarządzanie zmiennymi. Pracują dla nas, a nie na odwrót. W rzeczywistości można uznać za niegrzeczne programowanie, aby nie umieszczać niektórych danych w globalnych. Ponieważ niekoniecznie wiem lepiej niż następny facet, a jeśli chce introspekcji lub modyfikacji mojego kodu lub modułu, to po prostu dobrze i sąsiedzko.