🚀 go-pugleaf

On 2011-10-14, MaRc <tuksmr@gmail.com> wrote:
> męczę się z prostą rzeczą. nie mogę znaleźć odpowiedzi w żadnym z 
> przykładów.

Shift ci nie działa. Zmień klawiaturę.

> otóż piszę prosty skrypt cgi w perlu i chcę zrobić pętlę for 
> wewnątrz obiektu.

Nieprawda. W podanym przykładzie nie masz czegokolwiek przypominającego
obiekt.

> no ale ja chce dynamiczne wiersze coś w tym stylu:
> #v+
>   print table({-border=>undef},
>   caption('When Should You Eat Your Vegetables?'),
> Tr({-align=>'CENTER',-valign=>'TOP'},
>   [
> th(['Vegetable', 'Breakfast','Lunch','Dinner']),
>
> td(['Tomatoes' , 'no', 'yes', 'yes']),
>
> foreach $i (1..10){
> td(['$i' , 'a','b', 'c']),
> }
>
> td(['Broccoli' , 'no', 'no', 'yes']),
>   td(['Onions' , 'yes','yes', 'yes']),
>
> ]
> )
> );
> #v-

1. Używaj wcięć. Wcięcia nie bolą, a czyta się to lepiej.
2. Konstrukcja "$x" z reguły jest głupia, bo zwraca to samo co po prostu
   $x.
3. Chcesz użyć tutaj funkcji map{}, tylko nie wiesz pod jaką nazwą jej
   szukać.
4. Głupio tu robisz chcąc użyć funkcji map{}. Tak naprawdę chcesz
   doczytać `perldoc CGI', paragraf "SPECIAL FORMS FOR IMPORTING
   HTML-TAG FUNCTIONS".

> wiem, że można to wygenerować standardowo linia po lini i to działa, ale 
> chciałem w obiekcie.

Proszę się odpieprzyć od słowa "obiekt", bo nie wiesz co to znaczy
w programowaniu. Nie masz tu nic, co by obiekt (OOP) choćby
przypominało.

-- 
Secunia non olet.
Stanislaw Klekot

W dniu 14.10.2011 23:41, Stachu 'Dozzie' K. pisze:
> Nieprawda. W podanym przykładzie nie masz czegokolwiek przypominającego
> obiekt.

to nie jest obiektowe?:
#v+
my $q = CGI->new;
#v-
zródło perldoc:
"There are two styles of programming with CGI.pm, an object-oriented 
style and a function-oriented style. In the object-oriented style you 
create one or more CGI objects and then use object methods to create the 
various elements of the page. Each CGI object starts out with the list 
of named parameters that were passed to your CGI script by the server. 
You can modify the objects, save them to a file or database and recreate 
them."
qrde, piszą o obiektach, no chyba że mój angielski jest tak słaby, że 
nie wiem co oznacza wyraz "object", albo Ty wiesz więcej niż perldoc. 
Jeśli tak, to podziel się wiedzą.


> 2. Konstrukcja "$x" z reguły jest głupia, bo zwraca to samo co po prostu
>     $x.

jaki $x? to tylko był przykład, nie produkcyjny kod

> 3. Chcesz użyć tutaj funkcji map{}, tylko nie wiesz pod jaką nazwą jej
>     szukać.

??

> 4. Głupio tu robisz chcąc użyć funkcji map{}. Tak naprawdę chcesz
>     doczytać `perldoc CGI', paragraf "SPECIAL FORMS FOR IMPORTING
>     HTML-TAG FUNCTIONS".

ten paragraf akurat jest krótki i przeczytany. Akurat ten styl 
programowania wiąże się z defautlowym obiektem cgi do którego dostaję 
się bezpośrednio. To jest zrozumiałe.


> Proszę się odpieprzyć od słowa "obiekt", bo nie wiesz co to znaczy
> w programowaniu. Nie masz tu nic, co by obiekt (OOP) choćby
> przypominało.
>

no tak stachu, Ty zawsze masz racje. a perldoc musi się mylić.
"In the function-oriented style, there is one default CGI object that 
you rarely deal with directly"
źródło: http://perldoc.perl.org/CGI.html


suma sumarum, nadal nie znam odpowiedzi na zadane pytanie :(
-- 
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a 
wówczas pobije cię swoimi argumentami.

MaRc wrote:
> td(['Tomatoes' , 'no', 'yes', 'yes']),
>
> foreach $i (1..10){
> td(['$i' , 'a','b', 'c']),
> }
>
> td(['Broccoli' , 'no', 'no', 'yes']),
>
> [...]
>
> no ale po dodaniu foreach wywala mi błądną składnie
> syntax error at /usr/lib/cgi-bin/index.pl line 98, near "foreach "
> syntax error at /usr/lib/cgi-bin/index.pl line 103, near ")
> ]"
> syntax error at /usr/lib/cgi-bin/index.pl line 122, near "}"
> Execution of /usr/lib/cgi-bin/index.pl aborted due to compilation errors.

Nic dziwnego, skoro parser spodziewa się w miejscu pętli foreach'a jakiejś
wartości, która byłaby parametrem dla funkcji td(), a foreach jest
konstrukcją składniową. Poza tym, jak już, to jakiś przecinek za pętlą
by się przydał żeby oddzielić to od kolejnego parametru (ale to też nie
pomoże).

Niestety, w Perlu nie ma łatwej metody na tworzenie generatorów (czyli
tego, czego byś tu potrzebował). Można jednak uzyskać podobną funkcjonalność
eval'em albo funkcją anonimową.

Wstaw zamiast pętli foreach'a takie coś:

#v+
eval {
  local @_;
  foreach my $i (1 .. 10) {
    push @_, td([$i, 'a', 'b', 'c']);
  }
  @_;
},
#v-

to powinno dać to, czego oczekujesz.

W dniu 15.10.2011 13:29, Adam Osuchowski pisze:
> Wstaw zamiast pętli foreach'a takie coś:
>
> #v+
> eval {
>    local @_;
>    foreach my $i (1 .. 10) {
>      push @_, td([$i, 'a', 'b', 'c']);
>    }
>    @_;
> },
> #v-
>
> to powinno dać to, czego oczekujesz.

ok, wielkie dzięki, o coś tak konkretnego mi chodziło. Znaczy, że się da :)
Pozdrawiam

-- 
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a 
wówczas pobije cię swoimi argumentami.

On 2011-10-15, MaRc <tuksmr@gmail.com> wrote:
> W dniu 14.10.2011 23:41, Stachu 'Dozzie' K. pisze:
>> Nieprawda. W podanym przykładzie nie masz czegokolwiek przypominającego
>> obiekt.
>
> to nie jest obiektowe?:
> #v+
> my $q = CGI->new;
> #v-

Ale ty nie użyłeś obiektu CGI, tylko suchych funkcji wyeksportowanych
przez moduł.

> qrde, piszą o obiektach, no chyba że mój angielski jest tak słaby, że 
> nie wiem co oznacza wyraz "object", albo Ty wiesz więcej niż perldoc. 
> Jeśli tak, to podziel się wiedzą.

Albo ty masz za małą wiedzę programistyczną. Doczytać coś
o programowaniu obiektowym, wtedy wrócimy do dyskusji.

>> 3. Chcesz użyć tutaj funkcji map{}, tylko nie wiesz pod jaką nazwą jej
>>     szukać.
>
> ??

Czytać do zrozumienia.

>> 4. Głupio tu robisz chcąc użyć funkcji map{}. Tak naprawdę chcesz
>>     doczytać `perldoc CGI', paragraf "SPECIAL FORMS FOR IMPORTING
>>     HTML-TAG FUNCTIONS".
>
> ten paragraf akurat jest krótki i przeczytany.

To czytać do zrozumienia.

> Akurat ten styl 
> programowania wiąże się z defautlowym obiektem cgi do którego dostaję 
> się bezpośrednio. To jest zrozumiałe.

Nie jest zrozumiałym co masz na myśli pisząc "do którego dostaję się
bezpośrednio".

>> Proszę się odpieprzyć od słowa "obiekt", bo nie wiesz co to znaczy
>> w programowaniu. Nie masz tu nic, co by obiekt (OOP) choćby
>> przypominało.
>>
>
> no tak stachu, Ty zawsze masz racje. a perldoc musi się mylić.
> "In the function-oriented style, there is one default CGI object that 
> you rarely deal with directly"
> źródło: http://perldoc.perl.org/CGI.html

A co to ma do rzeczy? Ty nie ruszałeś w ogóle obiektu w pokazanym tu
kawałku kodu. To że moduł CGI pod spodem czegoś takiego używa nijak nie
zmienia faktu, że ty w kodzie nie miałeś żadnego obiektu w użyciu. Same
funkcje.

> suma sumarum, nadal nie znam odpowiedzi na zadane pytanie :(

Bo nie umiesz czytać udzielonej ci odpowiedzi.

-- 
Secunia non olet.
Stanislaw Klekot

On 2011-10-15, Adam Osuchowski <someone@somewhere.com> wrote:
> Nic dziwnego, skoro parser spodziewa się w miejscu pętli foreach'a jakiejś
> wartości,
[...]
> Można jednak uzyskać podobną funkcjonalność
> eval'em albo funkcją anonimową.

Odłóż apostrof, bo sobie nim oko wybijesz.
http://poradnia.pwn.pl/lista.php?id=6142

> Wstaw zamiast pętli foreach'a takie coś:
>
> #v+
> eval {
>   local @_;
>   foreach my $i (1 .. 10) {
>     push @_, td([$i, 'a', 'b', 'c']);
>   }
>   @_;
> },
> #v-

Proponuję zapoznać się z funkcją map{}, a nie prezentować takie
paskudztwo. Proponuję też zapoznać się bliżej z funkcją local, bo
wstawiona tu jest nadużyciem.

No i warto wiedzieć, że ten eval{} może prowadzić do błędów trudnych do
wychwycenia, gdyby z jakiegoś powodu td(), push() albo cokolwiek innego
w tym bloku wywołało die(). Ogólnie evala należy unikać, dopóki nie wie
się dokładnie co się robi.

-- 
Secunia non olet.
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:
> Proponuję zapoznać się z funkcją map{}, a nie prezentować takie
> paskudztwo.

Paskudztwo? Może i paskudztwo, jak cały Perl, ale to ma działać, a nie ładnie
wyglądać. Jak lubisz kod rodem z galerii sztuki to pisz w Pythonie.

> Proponuję też zapoznać się bliżej z funkcją local, bo wstawiona tu jest
> nadużyciem.

Po pierwsze, skoro już jesteś takim purystą językowym i wytykasz innym nawet
najmniejsze niejednoznaczności, to wiedz, że local w Perlu nie jest funkcją.
Poczytaj o tym, co to są słowa kluczowe i operatory w językach programowania
oraz czym różnią się od funkcji.

Po drugie, nie, nie jest to nadużycie. Jeśli nie rozumiesz po co jest tu
local to również odsyłam do dokumentacji.

> No i warto wiedzieć, że ten eval{} może prowadzić do błędów trudnych do
> wychwycenia, gdyby z jakiegoś powodu td(), push() albo cokolwiek innego
> w tym bloku wywołało die().

No to spróbuj zrobić bez evala lub funkcji jakiś generator bardziej
skomplikowany niż proste przemapowanie. Chociażby taki, który by pozwalał
na przerwanie sterowania w dowolnym momencie albo warunkowe wstawianie
elementów. Życzę powodzenia. To, że w tym przypadku map też by zadziałał
nie oznacza, że eval nie zadziała, pomijając fakt, że ma większe możliwości.
Poza tym daję osobie zgłaszającej problem rozwiązanie ogólne, a nie
ograniczone, działające tylko dla konkretnych sytuacji.

> Ogólnie evala należy unikać, dopóki nie wie się dokładnie co się robi

Ale ja wiem co robię i użyłem go świadomie. Jeżeli masz problemy
z opanowaniem takich konstrukcji i przerasta Cię obsługa błędów w evalu,
to ponownie zaproponuję Ci Pythona. Jest zdecydowanie prostszy i ładniejszy
więc z pewnością unikniesz ,,błędów trudnych do wychwycenia'' i nie będzie
to wyglądało jak ,,paskudztwo''. Albo może zaproponuj developerom Perla
usunięcie evala z języka bo przecież kto jak kto, ale Ty nie możesz się
mylić.

Dyskusje o szkodliwości evala śmieszą mnie tak samo jak te o szkodliwości
goto. Akademiccy teoretycy, którzy z inżynierią mają niewiele wspólnego,
a w życiu nie napisali większego kawałka kodu, który miałby praktyczne
zastosowanie, wyciągają argumenty typu ,,nie wolno używać noża bo się można
skaleczyć''.

On 2011-10-16, Adam Osuchowski <someone@somewhere.com> wrote:
> Stachu 'Dozzie' K. wrote:
>> Proponuję zapoznać się z funkcją map{}, a nie prezentować takie
>> paskudztwo.
>
> Paskudztwo? Może i paskudztwo, jak cały Perl,

Bredzisz. Perl nie jest paskudztwem, co najwyżej pozwala na pisanie
paskudztwa. I na ogół paskudztwo piszą kretyni uważający że umieją pisać
w Perlu.

> ale to ma działać, a nie ładnie
> wyglądać.

Ma działać *oraz* ładnie wyglądać. Kod wyglądający jak psu z gardła
wyciągnięty to kod gówniany i za pisanie takiego powinno się wieszać za
jaja.

>> Proponuję też zapoznać się bliżej z funkcją local, bo wstawiona tu jest
>> nadużyciem.
>
> Po pierwsze, skoro już jesteś takim purystą językowym i wytykasz innym nawet
> najmniejsze niejednoznaczności, to wiedz, że local w Perlu nie jest funkcją.
> Poczytaj o tym, co to są słowa kluczowe i operatory w językach programowania
> oraz czym różnią się od funkcji.

To poczytaj jak się wywołuje local i my. Traktuje się je jak funkcje,
mają argumenty i mogą coś zwracać. Nazwanie my() i local() funkcjami
nie jest błędem merytorycznym.

I może zapoznaj się -- tak dla porównania -- z takim językiem jak Tcl,
gdzie nie ma nawet instrukcji sterujących, a jedynie wywołania funkcji
operujących na stringach.

> Po drugie, nie, nie jest to nadużycie. Jeśli nie rozumiesz po co jest tu
> local to również odsyłam do dokumentacji.

Ja rozumiem. To ty tu prawdopodobnie nie rozumiesz. Do tego do czego
użyłeś local, tu należałoby użyć `my @array'.

>> No i warto wiedzieć, że ten eval{} może prowadzić do błędów trudnych do
>> wychwycenia, gdyby z jakiegoś powodu td(), push() albo cokolwiek innego
>> w tym bloku wywołało die().
>
> No to spróbuj zrobić bez evala lub funkcji jakiś generator bardziej
> skomplikowany niż proste przemapowanie. Chociażby taki, który by pozwalał
> na przerwanie sterowania w dowolnym momencie albo warunkowe wstawianie
> elementów. Życzę powodzenia.

Nie zrozumiałeś. Po prawdzie, nie dziwi mnie to, bo w Perlu pisać
najwyraźniej nie umiesz. Słyszałeś o takiej funkcji jak do{}? Nie? To
doczytaj. `perldoc -f do'

> To, że w tym przypadku map też by zadziałał
> nie oznacza, że eval nie zadziała, pomijając fakt, że ma większe możliwości.
> Poza tym daję osobie zgłaszającej problem rozwiązanie ogólne, a nie
> ograniczone, działające tylko dla konkretnych sytuacji.

Rozwiązaniem jeszcze ogólniejszym jest napisać parser uniwersalnego
języka programowania, bo można sobie w nim (w tym nowym języku)
oprogramować wszystko.

>> Ogólnie evala należy unikać, dopóki nie wie się dokładnie co się robi
>
> Ale ja wiem co robię i użyłem go świadomie.

Nie wiesz co robisz, skoro użyłeś go tam, gdzie do{} sprawi się równie
dobrze, a nie wprowadzi wad które podałem.

> Jeżeli masz problemy
> z opanowaniem takich konstrukcji i przerasta Cię obsługa błędów w evalu,
> to ponownie zaproponuję Ci Pythona.

Ja umiem obsłużyć błędy z evala. Ale wcale nie znaczy to że mam ochotę
za każdym jednym pieprzonym razem te błędy obsługiwać tylko po to, żeby
złapanym die() rzucić dalej. To raczej ty nie widziałeś na oczy kodu
dłuższego niż dwieście linii i pisanego przez czas dłuższy niż dwa
tygodnie.

> Dyskusje o szkodliwości evala śmieszą mnie tak samo jak te o szkodliwości
> goto. Akademiccy teoretycy, którzy z inżynierią mają niewiele wspólnego,
> a w życiu nie napisali większego kawałka kodu, który miałby praktyczne
> zastosowanie, wyciągają argumenty typu ,,nie wolno używać noża bo się można
> skaleczyć''.

Śmieszą mnie argumenty o zaletach i przewagach evala z ust osobnika,
który nie zna nawet funkcji do{} i nie potrafi przewidzieć, że
dokładanie obsługi błędów tam, gdzie błąd mógłby się spokojnie
propagować bez przeszkód, jest niepotrzebne i jest głupotą.

-- 
Secunia non olet.
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:
> Bredzisz. Perl nie jest paskudztwem, co najwyżej pozwala na pisanie
> paskudztwa. I na ogół paskudztwo piszą kretyni uważający że umieją pisać
> w Perlu.
> Ma działać *oraz* ładnie wyglądać. Kod wyglądający jak psu z gardła
> wyciągnięty to kod gówniany i za pisanie takiego powinno się wieszać za
> jaja.

Oo, widzę, że się skończyły merytoryczne argumenty i zaczęło się obrażanie.
Jak tak widzę Twoje posty to się zastanawiam, czy to czasami tylko ktoś nie
robi badań socjologicznych nad reakcjami ludzi w Internecie na trollowanie,
bo merytorycznych informacji to jest tu prawie że zero.

> To poczytaj jak się wywołuje local i my. Traktuje się je jak funkcje,
> mają argumenty i mogą coś zwracać. Nazwanie my() i local() funkcjami
> nie jest błędem merytorycznym.

No proszę, poważnie? Tylko, że Ty czepiasz się u innych takich samych
szczegółów. I założę się, że gdyby to ktoś inny powiedział że local jest
funkcją, zje*ałbyś go z góry na dół. A tymczasem sam się dałeś złapać
we własną pułapkę.

> Ja rozumiem. To ty tu prawdopodobnie nie rozumiesz. Do tego do czego
> użyłeś local, tu należałoby użyć `my @array'.

Użyłem local bo ,,my @_'' jest nielegalne. Zrobienie ,,my @array'' byłoby
identyczne w skutkach z ew. mikroskopijnym wpływem na wydajność (i to nawet
nie wiem na czyją korzyść). Gdzie więc to nadużycie, specjalisto?

> Nie zrozumiałeś. Po prawdzie, nie dziwi mnie to, bo w Perlu pisać
> najwyraźniej nie umiesz.

Ok, to Twoja opinia, masz prawo ją mieć, a mnie nie chce się Cię przekonywać,
jak jest naprawdę, więc niech Ci będzie.

> Słyszałeś o takiej funkcji jak do{}? Nie? To doczytaj. `perldoc -f do'

Słyszałem. I uważam, że do jest mniej elastyczne od evala. Chociażby
w kwestii przerywania sterowania, o czym pisałem.

> Rozwiązaniem jeszcze ogólniejszym jest napisać parser uniwersalnego
> języka programowania, bo można sobie w nim (w tym nowym języku)
> oprogramować wszystko.

No i na tym właśnie polega umiejętność programowania, której widać Tobie
brakuje: umieć zrobić rzeczy na takim stopniu skomplikowania i uniwersalności
żeby było użyteczne ale żeby nie przesadzić.

> Nie wiesz co robisz, skoro użyłeś go tam, gdzie do{} sprawi się równie
> dobrze, a nie wprowadzi wad które podałem.

To, że w Twoim mniemaniu to jest wada, nie oznacza, że tak jest naprawdę
albo, że jest tak w każdym przypadku. Skąd wiesz, czy w tym miejscu
akurat jest akceptowalne przerwanie całego programu tylko dlatego, że
się nie wykonał jakiś generator? eval właśnie ładnie to ukryje.

Poza tym, jeżeli mój oryginalny kod jest paskudztwem, to zamiana local na my
i eval na do nic w tej kwestii nie zmienia. Dyskusja o wyższości jednego nad
drugim jest czysto akademicka, co tym bardziej skłania mnie do wniosku, że
Twoje posty mają na celu trollowanie, a nie rzetelną dyskusję. Tym bardziej
że moje rozwiązanie działa, więc nie jest to kwestia ewidentnego błędu
rzeczowego, a jedynie Twojego zamiłowania do którejś z konstrukcji języka.

> Ja umiem obsłużyć błędy z evala. Ale wcale nie znaczy to że mam ochotę
> za każdym jednym pieprzonym razem te błędy obsługiwać tylko po to, żeby
> złapanym die() rzucić dalej.

To sobie użyj do. Można było to od razu napisać, zamiast mądrzyć się 
na temat obiektów i nomenklatury albo rzucać tekstami o ,,paskudztwie''
itp. nie mających pokrycia w faktach. Czemuś tego nie zrobił?

W tak prostym przykładzie jak był podany, eval praktycznie nie różni się
niczym od do. Natomiast w ogólnym przypadku eval jest bardziej elastyczny.

> To raczej ty nie widziałeś na oczy kodu dłuższego niż dwieście linii
> i pisanego przez czas dłuższy niż dwa tygodnie.

Tak, tak, masz absolutną rację. Nigdy nie widziałem takiego kodu, w Perlu
piszę od wczoraj, a w ogóle to pierwszy kod napisałem przedwczoraj. Jasne...
Niewiarygodne, z jaką łatwością przychodzi Ci rzucanie pustymi słowami na
tematy o których nic nie wiesz.

> Śmieszą mnie argumenty o zaletach i przewagach evala z ust osobnika,
> który nie zna nawet funkcji do{} i nie potrafi przewidzieć, że
> dokładanie obsługi błędów tam, gdzie błąd mógłby się spokojnie
> propagować bez przeszkód, jest niepotrzebne i jest głupotą.

A skąd wiesz czy znam czy nie? To, że mam inne zdanie na jego stosowanie
od Ciebie nie oznacza, że nie znam tej konstrukcji jak również, że nie
stosuję jej tam gdzie może być przydatna.

On 2011-10-16, Adam Osuchowski <someone@somewhere.com> wrote:
> Stachu 'Dozzie' K. wrote:
>> Bredzisz. Perl nie jest paskudztwem, co najwyżej pozwala na pisanie
>> paskudztwa. I na ogół paskudztwo piszą kretyni uważający że umieją pisać
>> w Perlu.
>> Ma działać *oraz* ładnie wyglądać. Kod wyglądający jak psu z gardła
>> wyciągnięty to kod gówniany i za pisanie takiego powinno się wieszać za
>> jaja.
>
> Oo, widzę, że się skończyły merytoryczne argumenty i zaczęło się obrażanie.

Jeszcze nie. Nie nazwałem cię jeszcze kretynem (innymi sprawami są czy
się poczuwasz do tego określenia i co ja o tobie myślę).

Poza tym, czy twoim zdaniem dobry kod może wyglądać jak papka
z odchodów?

>> Ja rozumiem. To ty tu prawdopodobnie nie rozumiesz. Do tego do czego
>> użyłeś local, tu należałoby użyć `my @array'.
>
> Użyłem local bo ,,my @_'' jest nielegalne. Zrobienie ,,my @array'' byłoby
> identyczne w skutkach z ew. mikroskopijnym wpływem na wydajność (i to nawet
> nie wiem na czyją korzyść). Gdzie więc to nadużycie, specjalisto?

Nadużycie jest takie, że używasz zlokalizowanej zmiennej globalnej
w charakterze zmiennej lokalnej. Co nie służy do tego.

>> Nie zrozumiałeś. Po prawdzie, nie dziwi mnie to, bo w Perlu pisać
>> najwyraźniej nie umiesz.
>
> Ok, to Twoja opinia, masz prawo ją mieć, a mnie nie chce się Cię przekonywać,
> jak jest naprawdę, więc niech Ci będzie.
>
>> Słyszałeś o takiej funkcji jak do{}? Nie? To doczytaj. `perldoc -f do'
>
> Słyszałem. I uważam, że do jest mniej elastyczne od evala. Chociażby
> w kwestii przerywania sterowania, o czym pisałem.

No jasne. Lepiej jest wprowadzić konstrukcję, w której trzeba dbać
dodatkowo o obsługę błędów, co może prowadzić do trudnych do
zdiagnozowania błędów.

>> Rozwiązaniem jeszcze ogólniejszym jest napisać parser uniwersalnego
>> języka programowania, bo można sobie w nim (w tym nowym języku)
>> oprogramować wszystko.
>
> No i na tym właśnie polega umiejętność programowania, której widać Tobie
> brakuje: umieć zrobić rzeczy na takim stopniu skomplikowania i uniwersalności
> żeby było użyteczne ale żeby nie przesadzić.

No tobie brakuje właśnie umiejętności programowania. Przesadziłeś
z evalem i przesadziłeś z local.

>> Nie wiesz co robisz, skoro użyłeś go tam, gdzie do{} sprawi się równie
>> dobrze, a nie wprowadzi wad które podałem.
>
> To, że w Twoim mniemaniu to jest wada, nie oznacza, że tak jest naprawdę
> albo, że jest tak w każdym przypadku. Skąd wiesz, czy w tym miejscu
> akurat jest akceptowalne przerwanie całego programu tylko dlatego, że
> się nie wykonał jakiś generator? eval właśnie ładnie to ukryje.

Wtedy się dodaje komentarz że eval jest potrzebny. Z twojego przykładu
nie widać żeby był potrzebny, a wprowadza coś, co w przyszłości trudno
się będzie debuggować. W takim przypadku należało użyć do{}.

> Poza tym, jeżeli mój oryginalny kod jest paskudztwem, to zamiana local na my
> i eval na do nic w tej kwestii nie zmienia.

Oczywiście. W pierwszym rzędzie lepiej było utworzyć tymczasową tablicę,
wypełnić ją i dopiero wstawić ją w miejscu kodu. Byłoby czytelniej
i bardziej elegancko.

> Dyskusja o wyższości jednego nad
> drugim jest czysto akademicka, co tym bardziej skłania mnie do wniosku, że
> Twoje posty mają na celu trollowanie, a nie rzetelną dyskusję. Tym bardziej
> że moje rozwiązanie działa, więc nie jest to kwestia ewidentnego błędu
> rzeczowego,

To się nazywa błędy stylistyczne. Kod nie tylko ma działać. Ma jeszcze
nie wyglądać jak kupa gówna, bo później się to źle poprawia.

>> Ja umiem obsłużyć błędy z evala. Ale wcale nie znaczy to że mam ochotę
>> za każdym jednym pieprzonym razem te błędy obsługiwać tylko po to, żeby
>> złapanym die() rzucić dalej.
>
> To sobie użyj do. Można było to od razu napisać, zamiast mądrzyć się 
> na temat obiektów i nomenklatury albo rzucać tekstami o ,,paskudztwie''
> itp. nie mających pokrycia w faktach. Czemuś tego nie zrobił?

Bo ma pokrycie w faktach. A czemu ty nie wyciągnąłeś na swoją obronę
funkcji do{}?

> W tak prostym przykładzie jak był podany, eval praktycznie nie różni się
> niczym od do. Natomiast w ogólnym przypadku eval jest bardziej elastyczny.

I przez to trudniejszy w poprawnym i bezpiecznym użyciu.

>> To raczej ty nie widziałeś na oczy kodu dłuższego niż dwieście linii
>> i pisanego przez czas dłuższy niż dwa tygodnie.
>
> Tak, tak, masz absolutną rację.

Przepraszam, ale taki wniosek mi się nasuwa czytając twój przykład
i twoje argumenty.

> Nigdy nie widziałem takiego kodu, w Perlu
> piszę od wczoraj, a w ogóle to pierwszy kod napisałem przedwczoraj. Jasne...
> Niewiarygodne, z jaką łatwością przychodzi Ci rzucanie pustymi słowami na
> tematy o których nic nie wiesz.

To są wnioski z dyskusji. Nie znam żadnego doświadczonego programisty,
który by wolał bardziej kosztowną metodę wykonania zadania (eval{}
z koniecznością obsługi die()) tylko dlatego, że teoria mówi, że ta
trudniejsza metoda jest bardziej ogólna, mimo że zadanie wcale nie
wymaga ogólności.

>> Śmieszą mnie argumenty o zaletach i przewagach evala z ust osobnika,
>> który nie zna nawet funkcji do{} i nie potrafi przewidzieć, że
>> dokładanie obsługi błędów tam, gdzie błąd mógłby się spokojnie
>> propagować bez przeszkód, jest niepotrzebne i jest głupotą.
>
> A skąd wiesz czy znam czy nie? To, że mam inne zdanie na jego stosowanie
> od Ciebie nie oznacza, że nie znam tej konstrukcji jak również, że nie
> stosuję jej tam gdzie może być przydatna.

No jakoś nie chce mi się w to wierzyć. I nie przekonałeś mnie do swojej
znajomości Perla i do swojej umiejętności (czy w ogóle chęci) pisania
dobrego, eleganckiego kodu.

-- 
Secunia non olet.
Stanislaw Klekot

In the darkest hour on Sun, 16 Oct 2011 14:14:07 +0000 (UTC),
Stachu 'Dozzie' K. <dozzie@go.eat.some.screws.spammer.invalid> screamed:
>>> Proponuję zapoznać się z funkcją map{}, a nie prezentować takie
>>> paskudztwo.
>>
>> Paskudztwo? Może i paskudztwo, jak cały Perl,
>
> Bredzisz. Perl nie jest paskudztwem, co najwyżej pozwala na pisanie
> paskudztwa.

Dla mnie też jest (czytaj: DGCC).

-- 
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:230B ]
[ 10:31:44 user up 12959 days, 22:26,  1 user, load average: 0.69, 0.04, 0.02 ]

          Just because I don't care doesn't meant I don't understand.