🚀 go-pugleaf

Dnia 13-11-2009 o 22:22:58 pakalk <pakalk@gmail.com> napisał(a):

>>> Jedyne co moge stwierdzic, to to, ze jesli
>>> zamienic bledy na wyjatki
>>
>> ... to wtedy to już nie byłby PHP. Taka zmiana to poważna robota, bo  
>> trzeba by poprawić wszystkie funkcje wbudowane, gdyż one nie rzucają  
>> wyjątków.
>
> To się realizuje przez error handler

Chyba śnisz. Jak sobie wyobrażasz i poprawną czytelną obsługę setek  
różnych funkcji w jednym miejcu? Co z tymi, które nie zwracają nawet  
errora?

> Zend Framework mnie zabil

tymi_Długimi_i_kretyńsko_NazwanymiNazwami? ;)

>> Django, Rails czy Merb  deklasują pehapowe frameworki.
>
> Railsow, czy Merba nie widzialem.

hehe, ty tak poważnie? No, może Merb nie jest aż tak popularny, ale że by  
Railsa nawet nie widzieć??

> Pod wzgledem funkcjonalnym Symfony tez jest niezle.

Symfony to żałosna (i wolna jak żółw) próba zaimplementowania Rails w PHP.  
To samo Cake.


> Jako skryptow mozna uzyc tez PHP

LOL. A dlaczego od razu nie Assemblera? Przecież PHP się do tego niewiele  
lepiej nadaje. Jak np. napiszesz skrypt który działa wielowątkowo skoro  
PHP nie ma wątków? :)

>> Ano pozostaje. Samoobsługowego serwera nie napiszesz w pehapie. Jeden  
>> przypadkowy fatal error i wszystko leży.
>
> Mozna to obejsc niby handlerem bufora wyjscia, ale to troche
> naciagane.

No to pokaż jak byś to obszedł i obsłużył.

>> > Zagladanie do logow tez nie jest takie straszne - szczegolnie,
>>
>> W wypadku pehapa nie masz innego wyjścia jak grzebać w logach i szukać  
>> miejsc które spowodowały kompletne załamanie się całej aplikacji.
>
> Z tym sie wciaz nie bede zgadzal, bo wg mnie w logach powinny byc dane
> o bledzie.

Czy także dane o błędzie który został poprawnie obsłużony przez kod? A  
trzymaj sobie w logach nawet wyniki losowań totolotka. Problem w tym, że w  
pehapie nie masz wyboru - grzebanie po faktach w logach to jedyna pewna  
metoda wyłapania błędów, o czywiście *po faktach*.

>> Oczywiście, wszystko po faktach. Najlepiej jak fatal error padnie  
>> podczas operacji finansowej, zakupu czegoś w sklepie internetowym.
>
> No to znaczy, ze na produkcji byla niestabilna wersja, co nie powinno
> miec miejsca.

Tyle teorii, a praktyka? Błędy w kodzie to codzienność, zwłaszcza w  
większym kodzie.

>> Jak ktoś lubi  ryzyko to niech używa pehapa i potem kłóci się z  
>> klientami że serwis działa jak kupa.
>
> Ale jak blad sie zdarzy w pythonie po operacji finansowej, to co? W
> magiczny sposob sie przywroci stan sprzed bledu? Raczej nie..

Nie mówie o błędzie w algorytmie, ale o błędzie który spowoduje załamanie  
się aplikacji. Błędzie, który pehap nie jest w stanie obsłużyć, a klient  
dostanie.. pustą stronę. Nie ma możliwości aby w pełni zabezpieczyć pehapa  
przed czymś takim.

> Zepsuc mozna wszedzie i wszystko. To, ze w PHP jest jak jest z bledami
> to "zasluga" liczby programistow - szczegolnie nieudolnych.

Jeśli masz na myśli to, że większość programistów pehapa jest nieudolna,  
to zgoda. Jeśli masz na myśli tych, co stworzyli pehapa, to też zgoda (to  
w końcu ich "zasługa" że stworzyli taki językowy potworek). Bo faktycznie  
trzeba być idiotą aby dodać do języka nieobsługiwalne błędy.

-- 
JZ http://blog.zabiello.com