🚀 go-pugleaf

On 31 Paź, 20:54, pakalk <pak...@gmail.com> wrote:
>
> > To, że nie można polegać na systemie  
> > wyjątków w PHP - to drugie.
>
> Czemu nie mozna?
try {
  jakis kod;
} catch(NieMatakiejKlasy $e) {
  print "chcialbym tu dotrzec";
}

póki kod przed w try jest ok, to ok
gdy dotrze do niestniejącejklasy wyjątku (literówka)
skończy się fatalem zamiast obsługą

>
>
>
> > Podobnie z modelem obiektowym. Za pierwszym razem (w wypadku PHP4) wyszło  
> > im to tak nieudacznie, że ten kod nie nadawał się do dalszych poprawek.  
>
> Lepiej o tym nie mowic. To byla tylko proteza.
>
> > Stąd model obiektowy w PHP5 został napisany od podstaw!
>
> Podobnie jak caly Zend Engine. A to zle?
>
>
>
> > Niestety, drugie podejście jest też niezbyt udane, bo twórcy pehapa  
> > zapatrzyli się trochę nie w tą stronę. Statycznie typowana, z silną  
> > typizacją Java to raczej kiepski wzorzec dla obiektowości w języku  
> > dynamicznym o słabej typizacji jakim jest PHP. Java nie jest językiem  
> > czystym obiektowo (poza tym model obiektowy Javy ma sporo wad).
>
> Jak dla mnie to ten model nie jest zly. Rzeklbym, ze uznany za
> swiatowy standard.
>
>
>
> > Wprowadzono do PHP zupełnie bezsensownie nieobiektowe konstrukcje w  
> > postaci metod statycznych,
>
> A to w pythonie nie ma? I dlaczego bezsensowne? Metody statyczne
> (klasowe) to standard OOP.

Metoda statyczna, jest to metodą nie używająca właściwości obiektu w
którym się znajduje,
tylko np dodająca 2 wartości przekazane jako argumenty. A do tego
służą funkcje odpowiednim
namespace/pakiecie. To nie jest standard OOP tylko proteza na
upychanie funkcji w namespace klasy
w Javie.

W pythonie wystarczy umieścić funkcję w pakiecie, nie potrzeba do tego
wymyślać klasy, w której
chciałbym mieć tą funkcję.

Jak już zostało wspomniane moim zdaniem portowanie do języka
dynamicznego jakim jest PHP wzorców i konstrukcji
z języka statycznego jest przerostem formy nad treścią, gdyż wiele
rozwiązań w javie jest stworzonych po to
by obchodzić jego statyczność i pozwolić wykonać to co w językach
dynamicznych można na dzień dobry.

>
> > interfejsów
>
> Interfejsy sa nieobiektowymi konstrukcjami?

Interfejsy nie są OOP. W przypadku niektórych implementacji używa się
ich do oznaczania oraz wymuszania spójności interfejsów klas.


>
> > czy głupi podział na prymitywy i  
> > obiekty.
>
> No fakt, ze latwiej ogarnac jedne typ zmiennych.
>
> > Gdyby "miszczowie" rzucili okiem na inne języki (z tej samej  
> > bajki, czyli dynamicznie typowane) to by może uniknęli głupich decyzji  
> > projektowych. No, ale jak to się mówi do trzech razy sztuka. Może trzecie  
> > podejście, jeśli do tego dorosną, w końcu im wyjdzie i PHP zbliży się  
> > trochę do nowocześniejszych języków programowania.
>
> Tzn. pythona bez podstawowego modyfikatora protected i __protezy dla
> private? :)

Protected i private też nie należą do OOP tylko do konkretnej
implementacji OOP.
Nie służą one do wymuszania ale do informowania o przeznaczeniu
konkretnej właściwości.

Problem się zaczyna przy dużym projekcie, wielu klasach dziedziczących
(płasko, nie głębokie drzewa),
gdy okazuje się, że protected z klasy bazowej sprawia spory problem
przy rozwijaniu projektu.

Tworzy się wtedy obejście na niepotrzebne blokowanie przy pomocy klas
friendly.

W pytonie wystarczy oznaczyć element jako protected '_' czy private
'__' i każdy normalny programista
zrozumie jego znaczenie, czyli nie używaj, a jak musisz to w klasach
ściśle powiązanych i musisz być przygotowany
na zmiany jeżeli nie ty rozwijasz pakiet z daną właściwością. Czyli
masz to samo co w Java, tylko bez zbędnego pisania
i bez problemów przy złożonych systemach.

Hermetyzacja nie oznacza blokowania klasy przed idiotami, tylko jasne
oznaczenie przeznaczenia klas i ich elementów.
W php czy w java oznaczenie jako private nie oznacza, że nie uda się
dostać do danej właściwości, bo można choć nie wprost (identycznie jak
w pythonie).

>
> > Moim zdaniem, ten język brnie w ślepy zaułek.
>
> Nie jest tak zle, ale bez zerwania z BC dalszy rozwoj moze byc niezle
> zblokowany.
>
> > Popełniono wiele błędów  
> > projektowych i nadal się w nie brnie. PHP też już dawno nie jest językiem  
> > prostym, robi się coraz bardziej skomplikowany,
>
> Ale nie zagmagtwany. Akurat nowe biblioteki sa bardziej uporzadkowane,
> a konstrukcje pomagaja w programowaniu.
>
> > tracąc swój początgkowy  
> > atut jakim była prostota.
>
> I co za tym idzie, mnostwo prostych magic_quotes itp.
>
> > Jest coraz wolniejszy w stosunku do innych  
> > języków dynamicznie typowanych.
>
> To zalezy od implementacji, ale nie znam dobrych benchamarkow.
>
>
>
> > Poza tym, przy pehapie tkwi dużo osób którzy w ogromnej większości  
> > prezentują bardzo niski poziom wiedzy na temat sztuki programowania. A  
> > każdy kto trochę więcej się podszkoli, szybko zaczyna tracić pierwotny  
> > entuzjazm fanboja i kieruje się do Pythona lub Ruby.
>
> Ci, ktorzy sie podszkola wola jave.

Nie uważam się za specjalistę od Java, więc lepiej przeczytać wywiad z
kimś kto chyba jest
 * http://www.artima.com/intv/aboutme.html

>
>
>
> > To prawda, że wciąż łatwiej znaleźć programistę PHP niż Ruby czy Pythona.  
> > Jednak w tym wypadku ilość nie oznacza jakości.
>
> Co tez nie znaczy, ze dobrych programistow PHP jest mniej niz Pythona
> czy Ruby.