Witam

Do utworzenia tego tematu skłoniła mnie lektura artykułu/kursu pod linkiem http://www.apohllo.pl/dydaktyka/ruby/intro/. Fajnie by było jakby w PHP-ie pojawiły się takie elementy jak metaprogramowanie, czy pełna obiektowość, prawda

Swoją drogą zawsze w PHP brakowało mi:

- wielokrotnego dziedziczenia (ech te nawyki z C++...) - wiem że w Symfony są mixin-y, ale dla mnie to półśrodek,
- przeciążania operatorów (zdaję sobię sprawę, że przy obecnej metodzie konwersji zmiennych jest to sprawa raczej przegrana) - podobno częściowo zaimplementowane w jakimś rozszerzeniu PECL, ale nigdy mi się nie udało tego w 100% uruchomić,
- właściwości (wiem, wiem, są metody __get i __set, ale to znów tylko półśrodek),
- takiego zaimplementowania uploadu plików, żeby można było bezproblemowo monitorować postęp wgrywania na serwer (znów - kilka rozwiązań krąży w sieci, ale żadnego nie udało mi się uruchomić, może za głupi jestem...),
EDIT: - przestrzenii nazw (zapomniał bym ).

A, i koniecznie przeczytajcie jak autor tekstu w w/w linku wypowiada się o swoich "przebojach" z PHP. Ręce opadają! Tak to jest jak się człowiek za coś bierze od dupy strony...
No i jeszcze jedno - nie programuję ani w Ruby-m, ani w Python-ie.

Bleeeee. Wielodziedziczenie to porażka. Już wiedzę te klasy Validator dziedziczące po Db i po Smarty
Wiesz po co jest przeciążanie operatorów? Żeby Cię z pracy nie zwolnili.
Wystarczy że w aplikacji przeciążysz wszystkie i już nikt się w tym nie połapie. Efekty które daje przeciągnie operatorów można bardzo ładnie osiągnąć implementując wszystkie operacji dla klas jako metody.
W Javie jakoś tego nie ma i nikt nie narzeka
Ot bajer. Co Ci dadzą właściwości?
No ale to nie ma związku z PHP. Tak jest skonstruowany protokół HTTP.

EDIT:Będą w 5.3, czyli za jakieś dwa/trzy miesiące.
Możesz potestować na snapsach.

Mi php pasuje. Ma wszystko, co trzebam aby byc skryptowym językiem do pisania aplikacji www. Do tych inne języki nadają się słabo ze względu na ich wydajność (np. java).
Wielokrotne dziedziczenie to występek przeciwko prawu naturalnemu i moralności - powinien być karany przez Świątą Inkwizycję OOP.

Pozdrawiam.

Eee tam, ja to bardzo lubiłem w C++. Mogli by to nawet domyślnie wyłączać w php.ini. Taki pomysł.



Jasne że można. Tak samo można wogóle nie używać klas i tego typu pierdół, nie? Chodzi o wygodę i prostotę. Idą twoim tokiem myślenia można równie dobrze powiedzieć: "Wiesz po co jest PHP? Żeby cię z pracy nie wywalili - napisałeś jakiś gówniany kod i teraz tylko ty umiesz się w nim połapać.". Głupota programistów nie jest dla mnie w tym miejscu argumentem.



A ja se kurna ponarzekam.



Bo są wygodne, eleganckie, przyjemnie się ich używa...



Nie chodzi mi tutaj o zady i walety HTTP. Chodzi o to, że sam stan pliku uploadowanego jest w PHP tak przetrzymywany, że monitorowanie tegoż stanu jest mooocno utrudnione. W PERL-u jakoś można.



Wot, dobre wieści...

Wielodziedziczenie byłoby fajne. Nie mogę dać
class Plugin_Database extends AdoDb extends Main_Plugin
{
}
Tego mi brakuje, bo ale nic nie poradzisz, zrestzą to osbliwy przypadek i z innymi się nie spotkałem :]

Niczego więcej mi nie brakuje Wszystko jest, aby porządnie napisać działającą stronę WWW. No jedynie ten upload plikow, ale jak powiedział Pan Mike nie od php to zależy.

Mylisz pojęcia. Java jest bardzo wydajna, jej wadą jest pamięciożerność.


Nie byłoby fajne. Tak jak napisał @mike. Już widzę te potworki, które dziedziczą po czy się da, tylko po to, by w jednym miejscu były wszystkie metody.

Mi brakuje:
- ścisłej kontroli typów,
- deklarowania typu zmiennej przekazywanej do funkcji (teraz jest tylko array oraz nazwa klasy) - nie pamiętam jak się to fachowo nazywa
- przeciążania metod (tak jak w Javie lub C#)
- domyślnego wywoływania konstruktora rodzica
- rzucania wyjątków, zamiast wyświetlania ostrzeżenia/błędu, przez niektóre funkcje wbudowane w PHP

A rzeczy, na które czekam to:
- przestrzenie nazw
- pełne wsparcie dla unikodu

- przeciążanie operatorów
- przeciążanie funkcji
- możliwość (ale nie konieczność) konkretnego określenia typu zmiennej
- wielodziedziczenie
- enumy
- struktury (wiem, że klasy to prawie to samo co struktury, ale jednak.)
- przestrzenie nazw

Coś tam jeszcze było. Jak mi się przypomni to edytuję posta

Chciałbym także, aby zamiast "->" był inny operator, np kropka ("."). Operator -> jest używany bardzo często, a wpisanie go jest stosunkowo trudne

Trochę wymagający jestem

EDIT:

Przypomniał mi się fajny bajer. To tylko bajer, ale czasem by się przydał. Chodzi o jakąś strukturę (podobną do np. ifów, switchów itp.), która by pozwalała na pracowanie na jakimś obiekcie. Np:

with($ludek){
cos1 = 'test1';
cos2 = 'test2';
cos3 = 'test3';
cos4 = 'test4';
}

by było równoważne z:
$ludek->cos1 = 'test1';
$ludek->cos2 = 'test2';
$ludek->cos3 = 'test3';
$ludek->cos4 = 'test4';

A Ruby, Python? Ruby jest o wiele lepiej przemyślany niż PHP (fakt że ma składnię, od której oczopląsu można dostać - to mnie do niego na razie zniechęca). A Python - szybcior.





Eee i tak mnie nie przekonacie.




Tutaj półśrodkiem (znowu) jest zmienna ilość argumentów funkcji/metody i brak deklarowania typu zmiennej przekazywanej do funkcji/metody.

Takie coś można uzyskać dzięki stdClass:

[PHP] pobierz, plaintext 
<?php
$obj = new stdClass();
$obj->var1 = 'a';
$obj->var2 = 'b';
$obj->var2 = 'c';
 
echo $obj->var2;
?>
[PHP] pobierz, plaintext 

Przypomniałem sobie o jeszcze jednej rzeczy, która czasami doprowadza mnie do szewskiej pasji. Wywalić funkcje include, include_once, require i require_once. Stworzyć jedną funkcję, która będzie dołączać pliki, a najlepiej jeśli pliki będą dołączanie automatycznie (oczywiście należy tak to sprytnie zrobić, by nie stracić na wydajności ).

__autoload()

Włączanie plików + autoloader

jak dla mnie to brakuje:
- przestrzenie nazw (ok beda ale na razie nie ma:P)
- troszke bardziej scisla kontrola typow, rowniez przy argumentach funkcji

to co mi natomiast nie podchodzi:
- zbyt duży bałagan jeśli chodzi o nazewnictwo funkcji, kolejność przekazywanych parametrów przy funkcjach z tej samej rodziny (raz trzeba przekazac jaki uchwyt innym razem nie) itp; generalnie niedbalstwo w przejrzystości nazewnictwa funkcji, klas..
- to że standardowe funkcje nie wyrzucają wyjątków tylko WARNINGI, ERRORY itd... skoro zaimplementowano wyjatki to chyba logiczne jest przerobienie dotychczasowych elementów jezyka by je wykorzystywały intensywnie

szkoda ze zbyt czesto phpowcy tłumaczą się "zachowaniem kompatybilności ze starszymi wersjami" np przy poruszaniu wyżej wymienionych przeze mnie zagadnień

Nie do końca mi o to chodziło. Używanie funkcji do ładowania plików wymaga ode mnie napisanie obsługi tego ładowania plików. A mi zależy na tym, by w "czarodziejski" sposób pliki same się ładowały
Bardzo podoba mi się rozwiązanie zastosowane w ZF, gdzie wystarczy zarejestrować automatyczne ładowanie klas i problem z głowy. Moim marzeniem jest pominięcie tej deklaracji

Temat stary jak świat, poruszany chociażby przy okazji tematu "jak podchodzić do zupy tagów". Ale masz rację - ja bym też to pchnął w przód i nie patrzył za siebię.



A nie przesadzasz troszkę? Jakaś kontrola dołączania plików musi być, a __autoload to bardzo fajne rozwiązanie.

Odczuwam brak:
- funkcji, która dopisałaby ciąg do początku pliku (teraz trzeba wczytywać plik do pamięci, co jest niezbyt wydajne)
- czegoś w rodzaju instrukcji goto w VB - żeby można było sobie skakać po kodzie
- żeby funkcją header (albo jakąś inną) można było pzesyłać tablicę $_POST - ułatwiłoby mi to pracę przy skomplikowanych formularzach wieloetapowych
- nie wiem czy są jakieś funkcje, które mogłyby powiedzieć coś na temat zużywanych zasobów. Fajnie byłoby odpalić funkcję, która zwróci czas ostatniego parsowania, zużycia pamięci, zmiennej która zajeła najwięcej pamięci itp.

Sie nie da.


Zajeb.... i jeszcze funkcji spagetti_code( $html_file, $php_file ), ktora polaczy oba pliki w jeden

------------


Straaasznie trudne, raz porzadnie napiszesz i masz (iteratory po katalogach + tokenizer/regexp) i juz.

Czytam ten wątek i zaczynam rozumieć dlaczego PHP jest często uważane za śmietnik i piaskownicę dla dzieci.
Przecież część z wymienionych tu rzeczy to pierdoły jakieś.

Programowanie polega na tworzeniu czegoś dzięki istniejącym narzędziom. I to miał na myśli (mam nadzieję) autor wątku.
Tu chodzi o rzeczy związanych z konstrukcją języka.

A Wy walicie .... bo mi jakiejś funkcji brakuje.
Jesteś programistą, napisz sobie!
To zacznie być problem języka wtedy kiedy on Ci na to nie pozwoli. Do tego momentu problemy szukaj w swoich umiejętnościach.

Nie do końca o to mi chodziło.

Zobacz to:

[PHP] pobierz, plaintext 
<?php
$obj = new stdClass();
$obj->var1 = 'a';
$obj->var2 = 'b';
$obj->var2 = 'c';
?>
[PHP] pobierz, plaintext 

i to o co mi chodziło:



widzisz różnicę ?

Widzę

Zawsze można użyć __set i __get.

a jednak nie widzisz

chodzi o to zeby nie pisac zawsze $this
we flashu tak jest (AS)

masz cos takiego

[PHP] pobierz, plaintext 
<?php
$obiekt = new Obiekt;
$obiekt->add('nowy');
$obiekt->resize();
$obiekt->save();
?>
[PHP] pobierz, plaintext 

a koledzie chodzilo o

[PHP] pobierz, plaintext 
<?php
with($obiekt){
add('nowy');
resize();
save();
}
?>
[PHP] pobierz, plaintext 

http://pl2.php.net/manual/en/function.set-error-handler.php

Odnośnie wydajności Javy: http://www.webhosting.pl/kategorie/program...ie_szybka_jak_c

Teraz dopiero widzę

empathon
Wiem, że jest taka funkcja, jednak jest to tylko okrętka. Dzięki temu przechwycisz błąd/ostrzeżenie, następnie przemielisz wielką funkcją, rzucisz wyjątek, a dopiero potem go obsłużysz - kiepska perspektywa.

Doprawdy nie spodziewałem się, że zarejestruję się kiedyś na tym forum, ale skoro trochę osób wchodzi z tego adresu na moją stronę, to wypadałoby się przynajmniej pokrótce odnieść do tego, co tu zostało napisane. W szczególności:



Nie wiem, czy od złej, czy od dobrej strony zabrałem się do PHP. Zadanie polegało na napisaniu systemu CMS w ciągu dwóch, czy trzech tygodni (dodam, że było to gdzieś w okolicach roku 2004), do strony, która była już zbudowana (przez grafika) w oparciu o statyczny HTML i Flasha. Kupiłem więc książkę z Helionu "Zaawansowane programowanie w PHP" (czy jakoś tak - czerwona okładka z twarzami programistów). Może to właśnie ta lektur sprowadziła mnie na złą drogę? Nikt jednak nie wspominał w niej ani o gotowych systemach CMS (całkiem zrozumiałem), ani o frameworkach do tworzenia stron (to już bardziej dziwne), ani nawet o szablonach (całkowicie niezrozumiałem). A przecież PHP jest językiem pomyślanym do tworzenia stron internetowych, czyż nie?


W każdym razie mając mocno ograniczony czas na przerobienie tej strony, nie mogłem poświęcić tygodnia czasu na zgłębianie jakiegoś gotowego CMS-a, czy innego tego typu rozwiązania. Tym bardziej, że nikt przy projektowaniu tej strony nie myślał w ogóle o tym problemie. Summa summarum - stronę napisałem, ale nie było to zbyt przyjemne doświadczenie, w szczególności biorąc pod uwagę fakt, że wszystko musiałem napisać od zera...

Przy kolejnym projekcie skorzystałem z Mambo - jeden z najlepszych systemów CMS napisanych w PHP. Skoro tak - to powinienem się czegoś nowego na nim nauczyć, większość rzeczy powinna być załatwiona automagicznie, czyż nie?
Prawa jest taka, że Mambo "niewiele" różniło się od mojego autorskiego projektu. Oczywiście nie chodzi mi tutaj o stopień jego zaawansowania od strony użytkownika końcowego, tylko o wnętrze - to co ogląda programiasta.

W szczególności - integracja z bazą danych praktycznie niewiele lepsza niż wywoływanie funkcji API (to, że ktoś to upchnął w jednym obiekcie, to żaden postęp); szablony HTML? - chyba nikt o nich nie słyszał - realizacja wzorca MVC polegała na umieszczeniu części kodu w jednym pliku, gdzie była przewaga PHP, a części w drugim, gdzie była przewaga HTML-a; migracje schematu DB - a co to takiego?; wtyczki - integracja z resztą systemu gorzej niż łopatologiczna; etc. etc.

Czy doprawdy zabrałem się za PHP od złej strony? W każdym razie to co oferował wtedy ten język (i nadal oferuje), a także to co powstało przy jego użyciu - raczej mi się nie spodobało...


A co do samego języka, jako języka (a nie platformy budowania aplikacji internetowych) - ma on parę zalet:
- hosting jest wszędzie
- jest w miarę szybki
- uruchomienie aplikacji w PHP jest bardzo proste
- jak ktoś zna nieco C lub Javę, to czuje się (niemal) jak w domu

To chyba wszystko dobrego co na jego temat mogę napisać. Nie chcę pisać nic złego, dlatego jeszcze raz zapytam o takie cechy (które można znaleźć w Rubim i/lub Phytonie):
- bloki (a co to w ogóle jest? po co to komu? apohllo.pl/dydaktyka/ruby/intro/struktury-jezyka)
- obiektowość - przecież jest w PHP! ok...
* ...a dokąd jest wysyłane np. mysql_query? do aktywnej bazy danych, tzn. jest sobie jakaś zmienna globalna (ktoś słyszał o wątkach?), która trzyma tę informację;
* ...a czym jest łańcuch znaków? - co za głupie pytanie, łańcuchem znaków... ok teraz rozumiem, do czego służy funkcja strlen; tablica? - tablicą, hmm, jej rozmiar badamy przez count, a obiekt? - obiektem, ilość jego "właściwości" badamy przez niech zgadę... prop_count, ależ skąd count! WTF?
- metaprogramowanie - nie będę się nad tym rozwodził, napiszę tylko tyle, że dzięki niemu np. dodanie wersjonowania (przechowywania historii modyfikacji stron) w Frameworku Ruby on Rails, sprowadza się do zainstalowania pluginu (jedna linijka w konsoli) i dodania odpowiedniego wpisu w modelu (acts_as_versioned), dodanie komentarzy do strony - jw.; dodanie ocen - jw.; wykorzystanie nowego języka szablonów - jw., etc., etc.

Podsumowując - nie będę mówił, że PHP jest zły, albo Ruby najlepszy, bo nie jest to prawda. Czasami jednak warto zapoznać się z innymi językami programownia (w szczególności polecam: LISP-a, Smalltalka oraz Erlanga), żeby zobaczyć, że pewne rzeczy mogą być prostsze, oczywistsze, przyjemniejsze, bardziej spójne, mniej podatne na błędy etc. etc. niż w naszym ukochanym języku. To trochę tak jak z nauką języków obcych - zawsze można powiedzięć, że polski jest najlepszy, najlepsiejszy, najnasiejszy i najcudowniejszy, ale jednak obecnie najwięcej osób mówi w angielskim, a kiedyś łacina była w powszechnym użyciu. Kiedy zna się te języki, to przynajmniej można spojrzeć na polski z innej strony i odkryć, że nie każdy język jest fleksyjny (vide angielski), a niektóre bardziej ekspresywne (vide łacina)...

apohllo: piszesz tak jakby ktos tutaj pisal ze PHP jest najlepszy, ze jest to jedyny sluszny jezyk - nie jest tak, bo tak jak napisales nie jest to najlepszy jezyk... ale da sie na tym zarobic
jezeli beda hostingi ruby to oczywiscie wtedy bedzie mozna sie bardziej zaglebic w ten jezyk. narazie ja przynajmniej traktuje to jako odskocznia od php:)

pozdrawiam

No coż z takimi opiniami najczęściej się spotykam, kiedy zaczynam coś mówić ludziom piszącym w PHP o Rubim... A co do zarobków - zwykla są lepsze niż dla programistów PHP:
- bo ludzi piszących w Rubim jest niewielu
- bo tworzenie systemu w RoR może być znacznie wydajniejsze.
Z ciekawostek warto zobaczyć tę ofertę pracy.



w USA i Europie jest już całkiem sporo firm, które hostują Rubiego/Railsy.
W Polsce jest również coraz lepiej. W tej chwili najlepszą ofertę ma chyba megiteam.pl

Ja również pozdrawiam.

@apohllo
Mówisz że są oferty pracy, mówisz że są serwery, ale ja do tej pory nie mogę tworzyć na PostgeSQL bo ludzie używają MySQL, więc że są nic nie zmienia, dopóki nie będzie ich mnóstwo. Jak kogoś pociąga ten język niech się go uczy.

Co do bloków, to mi się nie podobają, ale to moja sprawa, tak jak mi brakuje możliwości mocnego typowania przyjmowanych argumentów.
To że obiektowość w PHP kuleje to tez fakt, chociażby wspaniałość (to co ostatnio jedna osoba na tym forum pytała) zwracania zamiast instancji null, czy też nie wyrzucanie wyjątków (a jak już to jednego typu z opisowym opisem).
Co do konsekwencji nazewnictwa to się zgodzę, że go nie ma, ale przykład jest jest nietrafiony, bo to nie C gdzie mamy char*, tu jest to inny typ i powinien mieć swoje (i ma) działania. Co prawda powinni to ubrać w klasy, ale to już inny temat.
Co do wygody, to dobrze zbudowana aplikacja do zmiany, podłączenia plugin'ów wymaga tylko wpisu w konfiguracji... ale sam zauważałeś że darmowy CMS jest do niczego pod względem kodu, tak niestety jest że większość kody to śmietniki, są lepsze projekty, które się na szczęście rozwijają. (moim zdaniem np. Synfony, Propel)

Bloki, pośrod wielu interesujacych własności pozwalają znacznie uprościć kod, poprawiając jego czytelność - oczywiście o ile przeskoczy się "barierę bloku"


To jak wszystko - ma swoje wady i zalety (przy czym rozumiem, że chodzi Ci o statyczne (vs. dynamiczne) typizowanie - akurat Ruby jest silnie (vs. slabo) typizowany). Ale jeśli chcesz wykorzystać je do tworzenia "bezpiecznej" warstwy aplikacji, to możesz skorzystać np. z JRubiego, który pozwala na wykorzystanie w Rubim kodu Javy i vice versa.




Wyjaśnię może o co dokładnie mi chodziło - ponieważ każde z tych wywołań mówi nam coś o rozmiarze czegoś, to najlepiej byłoby, żeby były podobne/takie same. Dodam, że w Ruby można
to zrobić tak:

[1, 2, 3].size - zwraca rozmiar tablicy
"abc".size - zwraca długość łańcucha znaków
object.instance_variables.size - zwraca liczbę zmiennych instancyjnych danego obiektu

Nie trzeba zaglądać do API żeby odgadnąć znaczenie tych wywołań...

Tylko zalozenia projektowe jezykow byly inne:
- Ruby mial wprowadzac jak najmniej zaskoczenia (LOFA czy jakos tak), i dzialac tak jak myslisz ze bedzie dzialal
- a PHP - byl uproszczeniem Perla do przetwarzania formularzy i widocznie nikt sie za bardzo api nie przejmowal

I to wyjasnie wg mnie najwieksza wade php: jest to jezyk totalnie niekonsekwentny! A poza tym tak jak juz ktos wspominal, -> do wybierania elementow obiektu to totalna porazka w jezyku zorientowanym obiektowo.
Natomiast php ma ceche, ktorej wiele jezykow skryptowych nie posiada: mozliwosc typowania zmiennych w parametrach. Java mnie nauczyla jak to jest wazne. Inna sprawa, ze system typow w php to tez totalna porazka (czasem mam wrazenie, ze php dwa type: obiekt i typ elementarny - nie ma rozroznienia pomiedzy roznymi typami elementarnymi).

Mógłbym się w sumie powołać na to co napisałem wcześniej - głupota użytkowników to nie argument, ale... No właśnie, czy naprawdę chcielibyśmy takiej funkcji? Czasem może by i upraszczała kod, ale na pewno śmietnik zwiększyłby się n-krotnie. Poza tym wydaje mi się, że dobrze napisany kod nie potrzebuje tej funkcjonalności (i wcale nie będzie przez to mniej elegancki, czy czytelny) - u nas na studiach stanowczo odradzali używania goto przy większych projektach w C++, a w sumie raczej nie było okazji żeby sobie poskikać.



W Symfony masz zmienne flash.



Yeah



Hehe, chyba moja wina...



Skoczyłeś od razu na głęboką wodę nie mając pod ręką odpowiednich narzędzi. Inna sprawa, że to było dawno - chyba nie było wtedy nawet PHP 5 (sorry jeśli się mylę), albo dopiero raczkowało. Jakbyś się do PHP-a wziął tak jak do Ruby-ego, czyli z porządnym frameworkiem, to sprawa wyglądałaby zgoła inaczej. A co do tych książek, to miałem kiedyś "PHP 5 zaawansowane programowanie" (czy jakoś tak) i to raczej kiepski wybór jeśli chodzi o naukę tworzenia stron w PHP. Autorzy koncentrują się tam raczej na (tytułowym) programowaniu, czyli implementacji niektórych technik programistycznych w PHP. Trzeba było kupić "Kurs tworzenia stron internetowych PHP/MySQL", albo coś podobnego.



Weź pod uwagę, że trochę wody w Wiśle upłynęło i teraz możesz robić sobie dobrze takimi wynalazkami jak Symfony.



- bloki - bardzo fajna rzecz, ogromne uproszczenie,
- obiektowość
* a Propel, a Doctrine?
* eee, jesteś zbyt wygodnicki...
- pijesz do możliwości modyfikacji obiektu "w locie"? A dziedziczenie? Czy nie zapewnia nam podobnej funkcjonalności?

Moim zdaniem nie ma sensu zmieniać tak gwałtownie PHP jak to niektórzy proponują przez dodanie ścisłej kontroli typów; takie właściwości charakteryzują PHP i dzięki nim on jest właśnie wybierany do poszczególnych zadań.

Tylko przydałoby się tylko w php napisać jakiś mechanizm do dzielenia aplikacji na moduły; pojedyncze elementy wykonywalnego pliku, coś w stylu .dll. ale to tylko szczegół...

Czytałbyś łaskawie ze zrozumieniem, mowa jest o dodaniu możliwości wymuszenia typu przyjmowanego przez metodę (tudzież funkcję) a nie o tym aby to było wymagane. Bo doskonale wiem, że wymuszenie na wszystkich tego jest niemożliwe, ale osoby co piszą bardziej obiektowo mieli by lepsze życie (a możliwość przeciążania metod to było by cudowne, w końcu było by wiadomo co dane metody przyjmują bez dokumentacji)

P.S.
Bo już masz możliwość wymuszenia typu obieków i array, a brakuje typów podstawowych.

Sorry, ze odkopuje.

[PHP] pobierz, plaintext 
<?php
$klasa = new Klasa;
 
$klasa->metoda()->metoda2()->pole;
?>
[PHP] pobierz, plaintext 

... albo ...

[PHP] pobierz, plaintext 
<?php
class Klasa
{
   public function test(){
	 (...) 
	 return $this; // zwraca "siebie", ale nie kopie, tylko odwolanie.
   }
 
   public function zrobCosPoTest()
  {
	  (...)
	 return $this;
  }
 
  public function odpalCalosc()
  {
	   $this->test()->zrobCosPoTest();
 
	   // pozamiatane...
 
  }
 
}
?>
[PHP] pobierz, plaintext 

Tak sie da. Ale zeby to bylo naprawde cool (tak jak np. u mnie, gdzie odczytuje dane z bazy danych $tabela->id()->imie) trzeba troszke to php jednak znac.

Przy odrobienie checi w php mozna zrealizowac sobie swietne srodkowisko pracy, a i wiekszosc rzeczy o ktorych mowicie jest do zrobienia. Tylko nie trzeba czekac "az zrobia" tylko samemu sprobowac cos wymyslec i wykazac sie nieco ta swoja kreatywnoscia. Moze czasami lepiej sie zastanowic, jak rozwiazac dany problem przy uzyciu zabawek ktore mam, a nie marudzic, ze nie dali gotowych.

No dobra, ale to nie to samo. Mniejsza czytelność.

Co prawda można zrobić tak:

[PHP] pobierz, plaintext 
<?php
$klasa = new Klasa;
 
$klasa->
metoda()->
metoda2()->
pole;
?>
[PHP] pobierz, plaintext 

Ale to też nie to samo. Można się pogubić.

Idea fluent interfaces powstała dla czytelności. Nie wiem czego tam nie widzisz ale dla większości to jest bardzo czytelne

Powracając do głównego wątku mnie w PHP brakuje tylko funkcji, która by mi parzyła kawę ;/ wiec jak widac niewiele

Mi brakuje tylko kilku rzeczy:
1. Wątki;
2. Przestrzenie nazw (to będzie);
3. Blok finally dla try...catch (z tego "wspaniałomyślni" deweloperzy się wycofali a miało być w PHP 6.0)

No pewnie. To jest przydatne i często z tego korzystam, ale to nie ten sam efekt, o jakim myślałem.

Największą wadą PHP jest
1. Brak pełnej obiektowości, nie można np. sobie pisać
"Hello World ".trim();

2. Strasznie rozwlekła składnia języka, te
->, nawiasy, klamry, $, itp.

3. przeciążanie metod jest jakieś dziwne, tj. nie mogę sobie zapisać:
class Froo {
function bar(array $v) {}
fundcion bar(int $v) {}
//.. itp.
}

4. Śmietnik w API

5. W porównaniu do Rubiego trzeba pisać bardzo dużo kody, a wiadomo - im więcej kodu, tym więcej błędów.

6. ale największą wadę tego języka jest jego prostota, co niestety działa jak moron magnet :/