Czy php jest językiem obiektowym, ogólnego przeznaczenia? Opcje

[Krolik]

//wydzielone z głupich/ śmiesznych błedów php5 // DeyV

Maly OT:
Ludzie, opamietajcie sie. Naprawde uwierzyliscie w to co pisza na php.net i zend.com, ze php jest jezykiem obiektowym ogolnego przeznaczenia?

Tworcy php bardzo by chcieli, zeby tak sie stalo, ale niestety mocno brakuje im umiejetnosci jakie chociazby posiadaja inzynierowie Suna, ktorzy stworzyli Jave czy Bjarne S., ktory zaprojektowal C++. I stad takie smieszne bledy. Wyszla taka imitacja - jezyk pseudostrukturalny (nie jest w pelni strukturalne, bo nie ma silnej typizacji i kontroli struktur danych), pseudoobiektowy (z postow wyzej widac), i pseudomodularny (moduly przez include - fuj, no i brak garbage collectora, ale da sie przezyc). Ale do stron jest oczywiscie NA RAZIE full wypas.

Prawdziwe OOP jest w C++ i w Javie. Jak ktos chce robic strony w OOP to ma JSP albo serwlety (w C++ rowniez). Mam wrazenie, ze OOP w PHP5 wcale sie nie przyjmie. Bardzo malo osob korzystalo nawet z klas w PHP4, wiekszosc powstajacego kodu byla i jest strukturalna - bo na tym polu php sie sprawdza bo jest proste. Na tym zbudowalo sobie popularnosc. Jak ktos poznal sile programowania obiektowego, to zwykle porzuca php na rzecz duzo silniejszych narzedzi, zwlaszcza ze zaczynaja go draznic pewne up*** przy wiekszych projektach, ktorych nie ma w innych jezykach.

Zeby nie byc goloslownym wymienie tylko kika takich drobiazgow:
- Ogolnie niska wydajnosc w porownaniu z jezykami kompilowanymi, zwlaszcza na polu OOP.
- Automatyczne sprzatanie uzywa licznikow referencji. Technika stara, nieskuteczna i wszyscy sie z tego wycofuja. php wlasnie w to "wdeplo".
- Brak debuggera. Pozostaje "print" i "echo".
- Brak kontroli typow. W Javie i C++ wiekszosc bledow wykrywa kompilator. W php betatester (gdy skrypt zrobi cos dziwnego lub w najlepszym przypadku wypisze komunikat).
- Mimo roznych udogodnien w implementacji php nadal slabo wspiera projektowanie obiektowe - obiektow w php raczej uzywa sie jako narzedzi a nie jako "materialu budulcowego" strony. Tak, stosowanie OOP nie przynosi wtedy prawie zadnych korzysci.

Podsumowujac: php to nie C++ ani Java. Lukasz ma racje. Tworcy php traca swoj czas na glupoty, probuja sie popisac, a tylko ujawniaja swoj zenujacy brak profesjonalizmu.

Ten post edytował DeyV 16.11.2004, 22:37:47

[Imperior]

Brak debugera powiadasz...
http://dd.cron.ru/dbg/

[Krolik]

Dobra, wycofuje ten punkt. Debugger jest. Nawet fajna rzecz, aż muszę sobie ściągnąć...

[hawk]

jezyk pseudostrukturalny

Nie wiesz o czym piszesz. Język nie może być pseudostrukturalny.

nie jest w pelni strukturalne, bo nie ma silnej typizacji i kontroli struktur danych

Typizacja nie ma nic wspólnego ze strukturalnością. "Kontrola struktur danych" to jakaś bzdura, strukturalnosć odnosi się do struktury kodu.

pseudoobiektowy

Ciekawe czym się różni "obiektowy" od "pseudoobiektowy"?

pseudomodularny

C++ też jest pseudomodularny.

no i brak garbage collectora

C++ też nie ma garbage collectora. W zasadzie php ma znacznie lepsze garbage collection niż C++ .

Prawdziwe OOP jest w C++ i w Javie

Prawdziwie obiektowy to jest Smalltalk. C++ jako wzorcowy język obiektowy .

Podsumowując, stek bzdur. Szkoda, bo php ma sporo wad i można o nich dyskutować poważnie. Można i niepoważnie.

[DeyV]

Cieszę się, że to Ty, hawk, wypowiedziałeś się w tym temacie. Właśnie to było potrzebne, jednak mi wczoraj zabrakło na taką odpowiedź nerwów.

Najlepsze jednak jest to:

C++ też nie ma garbage collectora. W zasadzie php ma znacznie lepsze garbage collection niż C++

[Krolik]

Najlepsze jednak jest to:

C++ też nie ma garbage collectora. W zasadzie php ma znacznie lepsze garbage collection niż C++

php ma lepsze garbage collection niz C++? Na glowe upadliscie?
Dobra, ja nie wiedzialem o debuggerze do php (moj blad - sorry), ale widac, ze Wy macie blade pojecie o C++. Do C++ jest przynajmniej kilka roznych darmowych profesjonalnych garbage collectorow takich jak np. BDW (Boehm-Demers-Weiser), ktory dziala nawet w C bez koniecznosci modyfikowania istniejacych programow i bibliotek. Albo RTGC. Ostatecznie mozna tez uzyc SmartPoitnerow z C++ Boost, ktore sa jednak na poziomie php I tysiace ludzi tego uzywaja (glownie BDW). A C++ w .NET? Generacyjny, kopiujacy GC to co? Pies? Naukowcy pracowali nad tymi mechanizmami przez dziesiatki lat (i pracuja nadal), podczas gdy php ma odsmiecacz na poziomie tych z poczatku lat 70-tych. Zliczanie referencji bylo wlasnie juz wtedy znane.

C++ jako wzorcowy język obiektowy .

Nic takiego nie napisalem. M.IN. jest obiektowy i wspiera projektowanie obiekowe. php jako jezyk jest obiektowe, ale nie mozna sily tej obiektowosci wykorzystac, bo sposob pracy calej aplikacji jest typowo strukturalny (dane przetwarzane przez procesy tj. skrypty). Nie zaprojektujesz obiektowo aplikacji w php. Co najwyzej namalujesz diagram DFD albo ER. Ale to bedzie projekt STRUKTURALNY. Jest roznica miedzy projektowaniem obiektowym a programowaniem obiektowym.

C++ też jest pseudomodularny.

Nieprawda. W C++ modularnosc jest realizowana przez laczenie, a nie przez include. Include jest tylko udogodnieniem, bez ktorego mozna napisac program modularny. To spora roznica. Kod jest zorganizowany w moduly, z ktorych kazdy udostepnia dobrze zdefiniowany interfejs. To jest wlasnie progr. modularne.

[hawk]

Nie zaprojektujesz obiektowo aplikacji w php.

Trudno mi polemizować, jak ktoś twierdzi, że nie robię obiektowych aplikacji w php. Mi się wydawało że one są obiektowe - cała aplikacja składa się z obiektów, z dobrze zdefiniowanym interfejsem, i z interakcji między tymi obiektami. No ale jak ktoś mi mówi że nie mogę tego zrobić, to trudno.

A co do modularności: co w takim razie z #include? Albo, ze strony php, z include path? __autoload? auto.prepend?

php jako jezyk jest obiektowe, ale nie mozna sily tej obiektowosci wykorzystac, bo sposob pracy calej aplikacji jest typowo strukturalny (dane przetwarzane przez procesy tj. skrypty).

Każda aplikacja przetwarza dane przez procesy. Ew. przez skrypty/pliki exe/etc. Więc każda aplikacja jest typowo strukturalna?

[Krolik]

Chwytasz mnie za slowka: dobrze - jak sie uprzesz, to zaprojektujesz cala aplikacje obiektowo, ale nie widze wiekszego sensu tak robic, bo to troche jak uzywanie dlugopisu do wbijania gwozdzi. Na pewno mozesz zaprojektowac kazdy ze skryptow obiektowo, tu nie mam watpliwosci. W ktoryms watku ktos napisal, ze mozesz w php stosowac nawet MVC, tylko ze wtedy napotykasz wlasnie na taki problem, ze skrypt w php wykonuje sie na czas jednego zadania HTTP, a pozniej ginie. I w efekcie bedziesz miec duzo bardziej rozbudowany i prawdopodobnie mniej wydajny kod, niz gdybys to zrobil strukturalnie, wspomagajac sie klasami jedynie jako zestawem narzedzi. Ciezko jest zrobic obiekt o zasiegu calej aplikacji, a nie tylko pojedynczego wykonania skryptu. Trzeba sie uciekac do takich sztucznych metod jak serializacja, ciasteczka, zapis w bazie danych czy pliku itp. To mialem na mysli, ze php slabo wspiera projektowanie obiektowe.

A tak w ogole to granica miedzy tym czy cos jest bardziej strukturalne czy obiektowe jest wbrew pozorom dosc plynna. Wszystko zalezy jak na to patrzysz. Jak patrze na aplikacje zbudowane z EJB to traktuje ja jako zbior obiektow dostarczajacych sobie nawzajem odpowiednie uslugi, posiadajacych jakies wlasciwosci, stan, itp. wspoldzialajacych ze soba . Jak patrze na aplikacje php, to widze raczej zbior skryptow przetwarzajacych dane. Oczywiscie i tak aplikacja na EJB ostatecznie zostanie wykonana przez mikroprocesor, ktory nie rozumie nawet jezykow strukturalnych, a jedynie kod maszynowy i operuje nie na strukturach danych, a na liczbach... Wiec w tym sensie to zadna aplikacja nawet strukturalna nie jest, ale to jest kwestia implementacji, a nie projektu.

Jeszcze jeden przyklad roznicy "procesu" od "obiektu": wez np. programik copy.exe i programik msword.exe (ladny mi "programik" ). Ten pierwszy bierze jakies parametry na wejscie, cos wykonuje i zwraca jakies wyjscie (np. komunikat o bledzie). Drugiego nie opiszesz w ten sposob. Bardziej pasowalby opis jako obiekt, ktory mozna stworzyc (=uruchomic), wywolywac na nim okresone metody (z menu), odczytywac stan (monitor, drukarka) a na koncu zniszczyc wywolujac metode niszczaca, czyli File->Exit.

Ten pierwszy programik jest analogia do php, CGI, CF, ten drugi do np. serwletow Javy albo ASP.NET.

Mam nadzieje, ze teraz juz napisalem zrozumiale.

[bregovic]

@Krolik: IMHO masz po prostu bardzo zamknięte pojęcie obiektów - i dlatego uważasz że w php nie da się ich wykorzystać. Otóż jeżeli tylko przyjmiesz że każdy obiekt ma ograniczone życie - od requestu http do odpowiedzi na niego - to bez problemu będziesz mógł używać obiektów (zresztą jak sam napisałeś, możliwe jest serializowanie obiektów w sesjach - co wcale nie jest takie głupie).

Jeśli teraz zoptymalizujesz wszystkie twoje obiekty tak aby stworzenie ich nie zajmowało dużo czasu, to wciąż masz w kieszeni szybkość php - a jednocześnie proste obiektowe podejście do żeczy. I nawet MVC możesz wykożystać. Z tym że nie wbijasz żadnych gwoździ - bo tych gwoździ (które są czasem w aplikacjach nie-serverwowych) nie ma.

[hawk]

No to dotykamy tutaj największego chyba problemu php. Który jest ortogonalny do tego, czy robimy aplikację obiektową, czy nie. Czyli nietrwałości wszytkiego. I to jest poważny problem, bo choćby nawet php było szybkie, choćby tworzenie obiektów było zoptymalizowane, choćby sesje działały świetnie - to i tak strasznie utrudnia to myślenie o aplikacji, a nie o zbiorze skryptów. I tutaj przykład Królika z wordem itd jest w sam raz. Z tym że to już dla mnie nie jest kwestia obiektowości, bo obiektowo można napisać nawet program batchowy i ma to sens. Ale to już kwestia nazewnictwa.

Dlaczego w php nie ma serwera aplikacji? Żeby taki system oparty o MVC czy cokolwiek czekał na żądania i nie musiał co chwila wczytywać klas i łączyć się z bazą danych. Nawet mieliśmy z Gandalfem pomysł na realizację tego. Ale jakoś czasu nie ma.

[Krolik]

No wlasnie robie cos podobnego w C++ a Ty mnie hawk probowales zniechecic...
W C++ a nie w php ani w Javie z wielu wzgledow, o ktorych juz pisalem.

[bigZbig]

Panowie nie mnie tu rozstrzygac, czy php jest obiektowe, czy nie. Tworcy php zdaja sie usilnie je takim uczynic i nalezaloby raczej podyskutowac czy to daje nam rzeczywiscie jakies nowe, ogromne mozliwosci - oczywiście pamietajac do czego ten jezyk ma sluzyc. Moim skromnym zdaniem porownywanie php z C++ ma taki sens jak porownanie zmywarki z piecykiem elektrycznym. Oba urzadzenia pobieraja prad i do obu wklada sie garniki ;-). Nie użyłbym php do napisania systemu operacyjnego, tak jak nie wybralbym go do obrobki grafiki zamiast np. photoshopa

[Krolik]

Nikt tu nie porównuje ogólnie php do C++. Podałem tylko przykład, że obiektowość w php nie przynosi aż takich korzyści jak mogłaby, gdyby było coś takiego np. jak serwer aplikacyjny. Wtedy można byłoby sobie np. stworzyć pulę połączeń z bazą danych albo wygodnie wykorzystać model MVC mocno zwiększając przejrzystość i wydajność aplikacji. Łatwiej byłoby patrzeć na taką aplikację jak na zbiór obiektów, a nie jak na zbiór skryptów.

[bela]

Dlaczego w php nie ma serwera aplikacji? Żeby taki system oparty o MVC czy cokolwiek czekał na żądania i nie musiał co chwila wczytywać klas i łączyć się z bazą danych. Nawet mieliśmy z Gandalfem pomysł na realizację tego. Ale jakoś czasu nie ma.

jest mozliwe realizacja tego w php ?

[Seth]

Tak.

[bela]

a jest sens ?

[Krolik]

Sens jest, bo:
1) Zwiekszylaby sie wydajnosc.
2) Duze aplikacje mialyby bardziej przejrzysta strukture - skrypty nie musialyby sie zajmowac glupotami takimi jak np. zapis stanu.
3) Mozna byloby budowac eleganckie frameworki do tworzenia aplikacji w oparciu o MVC.
4) Ogolnie wszystko by wygladalo "bardziej profesjonalnie".

Jednak napisac serwer aplikcayjny w php dla php - hmmm... to dosyc ciekawe zadanie.
Moim zdaniem trudne, bo np. w samym jezyku php brakuje wsparcia dla wielowatkowosci i synchronizacji, a developerzy oficjalnie nie maja zamiaru tego dodac. Pewnie moznaby sie bez tego obyc, ale nie wiem, czy raczej zamiast serwera aplikacyjnego nie wyszedlby z tego kolejny system template'ow. Inny problem to zarzadzanie pamiecia. Sorry, ze sie znowu czepiam tego samego, ale mimo wszystko przy dlugo pracujacych aplikacjach slabosc odsmiecacza do cykli moze wszystko popsuc. Obecnie nie ma to wiekszego znaczenia bo i tak skrypty wykonuja sie krotko. A w serwerze aplikacyjnym takie rzeczy jak zarzadzanie zasobami i wspolbieznoscia maja bardzo duze znaczenie.

Ja bym bardziej widzial zrobienie takiego serwera poprzez wziecie zrodelek php i w nich pogrzebanie.

[bela]

@Krolik: nie zrozumiales mnie, wychodziło mi o wydajnosc

[Krolik]

Mysle, ze gdybys napisal to uzywajac jedynie php, to wydajnosc bylaby raczej niespecjalna. Ale polaczenie serwera napisanego np. w C lub C++ z interpreterem php wykonujacym "serwlety" php mogloby byc szybsze niz "zwykle" php. Co o tym sadzicie?

[Seth]

Z ta wydajnością php to troche przesadzasz. Owszem nie jest zbyt szybkie w porownaniu z servletami ale jest cos takiego jak MMCache, które znacząco przyspiesza dzialnie php.

Natomiast taki serwer Aplikacji napsiany w php mogl by się sprawidzić o ile tylko zadbali bysmy o usuwanie niepotrzebnych danych z pamieci.
A dlaczego w php, a nie np w Javie ? Ano dlatego, ze więcej tanich hostingów obsługuje php, a co za tym idzie jest to tańsze rozwiązanie.