🚀 go-pugleaf

On Nov 10, 2:39 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> On Fri, 06 Nov 2009 18:09:46 -0000, pakalk <pak...@gmail.com> wrote:
> > 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, więc mogę działać z tymi
funkcjami co są. Gorzej z fatal errorami, ale te też się da czasem
wyłapać (user_error ostatnio musialem, bo debilne smarty nie ma czegos
jak validateTemplate())

> W sumie musiałbyś napisać nową implementację pehapa. Nie ma  
> zmiłuj. To już lepiej z tym gównem się nie męczyć, ale użyć porządniej  
> zaprojektowanego języka.

Porządnej biblioteki. Można skopać każdy język zlymi bibliotekami ;)

> No bo poza ewentualną koniecznością utrzymania  
> jakiegoś wcześniej napisanego, dużego kodu, czy korzystania z gotowego  
> rozwiązania (np. do obsługi forum) to jaki sens pisać coś w PHP?

Szybko sie pisze, stosunkowo latwo rozprowadza.

> Ani to  
> szybkie, ani spójne i łatwiejsze w utrzymaniu.

Zend Framework mnie zabil

> Django, Rails czy Merb  
> deklasują pehapowe frameworki.

Railsow, czy Merba nie widzialem. Django jest bardzo fajne. Pod
wzgledem funkcjonalnym Symfony tez jest niezle.

> Zarówno wydajnościowo jak i funkcjonalnie.  
> Poza tym Python i Ruby to języki ogólnego zastosowania, można je więc użyć  
> w miejsce skryptóĻw bashowych, perlowych jak i do nawet tworzenia  
> aplikacji desktopowych.

Jako skryptow mozna uzyc tez PHP, do desktopowych raczej Java by sie
nadawala (oczywiscie nie z superwolnym swingiem). Jest jednak szybsza
kilka razy.

>
> > (no pozostaje FATAL ERROR),
>
> 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.

>
> > 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. Podczas developerki natomiast, mamy Firebuga. Wszystko co
sie wylapie, mozna wyslac na konsole.

> 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.

> 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..

Poza tym, operacje (wew) zazwyczaj opieraja sie na danych, a te
zabezpieczac powinny bazy danych. Zewnetrzne uslugi posiadaja
natomiast system transakcji, co tez zabezpieczyc powinno przed
bledami.

Zepsuc mozna wszedzie i wszystko. To, ze w PHP jest jak jest z bledami
to "zasluga" liczby programistow - szczegolnie nieudolnych. I tego, ze
jak ktos napisze takie mambo-jambo-joomle, to potem wszyscy korzystaja
i nie zwazaja na lepsze rozwiazania, bo "po co mi to jak mam to". W
pythonie jest inaczej, bo jak ktos cos pisze, to sie zastanawia. Choc
jak widze niektore modele zdarzen zaimplementowane w pythonie, to sie
zastanawiam, czy ktos za dlugo nie myslal ;)