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

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

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

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

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

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

C++ też jest pseudomodularny.

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

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.

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:

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.



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.



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.

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?


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

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.

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

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.

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.

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

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.

jest mozliwe realizacja tego w php ?

Tak.

a jest sens ?

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.

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

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?

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.

W sumie to ten cały wątek jest głupi. "Czy php jest językiem obiektowym". I dochodzisz do wniosku, Królik, że nie jest, bo (tu wstaw w zasadzie słuszne argumenty), więc się nie nadaje. Tymczasem to jest postawienie sprawy do góry nogami. To nieistotne, czy język jest obiektowy, czy nie. Istotne jest, czy mogę w nim zrobić ładny, obiektowy system. Co prawda, to drugie raczej wymaga tego pierwszego , ale przełożenie nie jest stuprocentowe. Ja w php programuję obiektowo, a przede wszystkim projektuję obiektowo, i wychodzi mi to mimo wszystko dobrze. To, że coś nie jest dobrze rozwinięte, albo dołożone na siłę, nie przeszkadza.

Zresztą, kilka przykładów, żeby unaocznić, że obiektowość nie jest celem, ale środkiem:

C++ ma warstwę obiektową dołożoną na siłę do C. I co? I nic. Nie będziemy z tego powodu robili krucjaty, że nie jest on w pełni obiektowy, nie warto było w ogóle zawracać sobie głowy i Stroustrup się mylił.

Java nie jest w pełni obiektowa. Java jest językiem hybrydowym, bo oprócz obiektów ma wartości, jak chociażby integer, boolean, itd. I wcale jej to nie przeszkadza, a nawet, IMHO, tak jest lepiej, wygodniej i wydajniej. Ale przecież obiektowośc na tym cierpi...

Smalltalk jest na pewno bardziej obiektowy niż Java. Ma na pewno swoich fanów, ale mi na przykład się nie podoba, bo jest dla mnie nieintuicyjny. Więcej nie znaczy lepiej.

Nawet taki Javascript, można zaryzykować stwierdzenie, jest bardziej obiektowy niż Java. W końcu tutaj wszystko jest jednym wielkim obiektem . Owszem, Javascript to bardzo ciekawy język, ale dużej aplikacji bym w nim nie napisał.


Podsumowując, takie podsumowanie jest nieuprawnione. Równie dobrze można stwierdzić (z pozycji Smalltalka), że Java słabo wspiera projektowanie obiektowe, i OOP nie przynosi prawie żadnych korzyści. Po prostu, to nie zależy od tego, czy język ma (tu wstaw dowolne słowo kluczowe na użytek OOP), tylko od czynnika ludzkiego - projektanta/programisty.

I to tak naprawdę chodzi, a nie o to, czy php jest wystarczająco obiektowy, czy nie.

A ja mam caly czas wrazenie, ze tu wlasciwie chodzi bardziej o pewien styl programowania. Obiekty w pewnym momencie stały się modne. To nowsza koncepcja od programowania stukturalnego i w zwiazku z tym ma niejako swiadczyc o profesjonalizmie tak jak np. typy zmiennych. Czy brak typow zmiennych w php jest jego wada czy zaleta? Bo niekiedy odnosze wrazenie, ze to co proste w oczach niektorych skazane jest na pogarde.

Spotkalem sie tutaj ze stwierdzeniem sugerujacym jakoby zapis stanu w javie i jego brak w php mialy swiadczyc o obiektowosci tego jezyka. Zdaje sobie sprawe z ograniczeń php i jestem jak najbardziej za tym aby je zmniejszyc, ale obiektowosc nie jest remedium na wszystkie bolaczki.

Zreszta php ma swoja specyfike i nie kazde rozwiazanie znane z innych jezykow sie w nim sprawdzi. Jako język skryptowy zawsze bedzie sie roznil od jezykow kompilowanych. Rozdział na metody publiczne i prywatne np. w php moim skromnym zdaniem nie ma wiekszego sensu skoro i tak majac dostep do zrodla clasy mozna to w kazdej chwili zmienic.

Oj, ma sens, i to duży.

Kontynuując twoje rozumowanie, public i private w językach takich jak C++ również nie ma sensu. Bo mając źródła możemy sobie zmienić, a nie mając źródeł (tylko np. plik wykonywalny), nie ma mowy o żadnym private, tylko jest czysty kod maszynowy.

Hermetyzacja w OOP nie jest po to, żebyś mógł zablokować komuś dostęp to wnętrza obiektu. Jak pokazał Gandalf w innym wątku, dostęp i tak jest, chociaż pośrednio. Hermetyzacja jest po to, żebyś pisał dobry kod.

[quote]Tworcy php bardzo by chcieli, zeby tak sie stalo, ale niestety mocno brakuje im umiejetnosci...[/quote]

a ja mysle ze bardzo bys chcial posiadac takie umiejetnosci ja developerzy ZENDa

[quote]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.
[/quote]

muahahahhahahahhaa
stary, rozwalasz mnie. prosze nie bij

tego pseudoxxx nie skompentuje bo juz wczensniej komentowano, ale do stron: skoro tak uwazasz, niech Ci bedzie

[quote]Prawdziwe OOP jest w C++ i w Javie. Jak ktos chce robic strony w OOP to ma JSP albo serwlety (w C++ rowniez).[/quote]

zaden CGI napisany w C++ nie jest tak szybki jak php, juz widzialem jednego cwaniaka ktory tak twierdzl i napisac oprogramowanie pod serwis xxx, ktory stal na php. nie dosc ze sie chlernie sypalo, to przy 20 000 roznych ip dziennie na tym serwisie, oprogramowanie chodzilo jakby chcialo a nia moglo, duzzzooo wolniej niz php. a co do jsp i servletow, owszem dobra sprawa, ale zeby pisac servlety czy kodowac w jsp warto by znac java, a tej nie nauczysz sie tak szybko jak php.

gdzies tam wspomniales o GC - a po cholere ci to w php, skoro czas zycia skryptu zaczyna sie w momencie zadania wykonania i konczy po... ?

[quote]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[/quote].

no nie wiem, mam zupelnie inne zdanie. ja w phpie koduje cos prawie 3 lata i caly czas strukturalnie, ale w pewnym momencie starlem sie z JAVA, C++, pozniej z Pythonem, wyszla 5 i juz nie pisze strukturalnie bo to samobojstwo na dluzsza mete.

a OOP w PHP5 jest naprawde dobre, moze juz cos poczarowac. w 4 bylo faktycznie jakby na ostatnia chwile upchniete, ze wzgledu na nowe tredy. ale w 5 juz jest ok i wlasnie od kiedy pojawila sie 5 zaczlem w phpie robic w oop, wczeniej nie moglem patrzec na ta zubozone w 4.

[quote]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.[/quote]

jakie uperdliwosci? php to swietne narzedzie developerskie mozna za jego pomoca sporo rzeczy napisac, a ze o tym nie wiesz widac dupa z ciebie a nie koder phpa. owsze, nie wszystko w nim sie zna i warto mie w glowie/pod reka inne narzedzia, ale to inna bajka.

[quote]Zeby nie byc goloslownym wymienie tylko kika takich drobiazgow:
- Ogolnie niska wydajnosc w porownaniu z jezykami kompilowanymi, zwlaszcza na polu OOP.[/quote]

pokaz mi stricte kompilowany jezyk ktory jest szybszy na sieci od phpa? to w java i pythonie to nie jest kompilowanie

[quote]- Automatyczne sprzatanie uzywa licznikow referencji. Technika stara, nieskuteczna i wszyscy sie z tego wycofuja. php wlasnie w to "wdeplo".[/quote]

w j2ee GC dziala w oparciu o ta technike jakbys nie wiedzial.


[quote]Brak debuggera. Pozostaje "print" i "echo".[/quote] - ta, wida "dobry" z ciebie koder


[quote]- 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).[/quote]

a po co Ci kontrola typow? a dobry koder po komunikacie warninu etc. wie jakiego typu jest blad i gdzie mniej wiecej jest i go zaraz usuwa. za to C jest wspaniale ze swoimi wskaznikami, zreszta delphi tez jak sie pisze roznego rodzaju listy inwersyjne etc. to jest bajka, raz mialem wskazniki na wskazniki na wskazniki na wskazniki a to byly ideksy roznych tablic, ktore byly ideksami etc... taka ogolnie masakra i mialem tam blad, pol dnia z debugerem go szukalem nim znalazlem, zatem podziekowal.


[quote]- 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.[/quote]

przynosci, w kolejnych projektach ktore sie sklada z klockow.

[quote]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. [/quote]

java jest tak wolna ze glowa boli, a C++ owszem jest pozadny jezyk, ale nie pozadzisz w nim na sieci. a swoja droga, wiesz jak autorzy ksiazek do pythona pisza o C++? ze to jezyk niskiego poziomu

bo przy pythonie czy java wlasnie tak wyglada.


i na koniec: zarowno php, java jak C++ to pozadne narzedzia, roznica jedynie w tym gdzie sa najmocniejsze, w ktorej dziedzinie zastosowac. jesli ktos np. probuje pisac aplikacje okieenkowe w phpie to jest samobojca (gtk power), jesli pisze www w C++ czytaj jak wczesniej, jesli w JAVA pisze gre 3d jak wczesniej etc. wiadomo o co chodzi. nie ma narzedzi doskonalych do wszystkiego, dlatego warto znac kilka jezykow.

Czy autor tematu dalej podtrzymuje swoje zdanie, ze OOP w PHP się nie przyjmie? Nostradamus to z Ciebie nie jest



---
Wiesz, skoro tak lubisz archeologię i historię to trzy lata temu nabijałeś posty z userem ~keNNyNAH, co powoduje, że razem z tym postem masz już dwa nabite.
Za kolejnego (trzeciego) masz ostrzeżenie
~mike

Z Ciebie za to jest archeolog

Co jest? Pomieszało się Wam obojgu coś? Jeden archeolog, drugi, ich tropiciel... Tropiciel następnym razem dostanie +20 (za oba).