python vs php - potrzebne argumenty
sze...@wytnij.gazeta.pl
Powstaje pewien projekt webowy i toczy siďż˝ dyskusja o technologii.
Kandydatami sďż˝ django oraz frameworki phpowe.
Znam django i osobi�cie nie mam co do niego w�tpliwo�ci
a w napisanie czytelnego i zarz�dzalnego kodu w php nie wierz�
- ale potrzebuj� przedstawi� to w postaci konkretnych argument�w,
obejmuj�cych funkcjonalno��, jako�� framework�w i wszelkie inne
czynniki maj�ce znaczenie. Wszelkie wypowiedzi, tak�e krytyczne,
mile widziane.
Jak dot�d przychodzi mi do g�owy to, �e:
- sensownie zaprojektowane frameworki phpowe s� w nowo�ci�
i nie umywaj� si� dojrza�o�ci�, dokumentacj� i ilo�ci� dodatk�w do django
- djangowy orm zjada phpowe wymys�y na �niadanie
- django ma panel admina
- python jako j�zyk bardziej zwi�z�y generuje kr�tszy, czytelniejszy i przez
to �atwiejszy w utrzymaniu kod
- python ma bibliotek� standardow� kt�ra jest zaprojektowana obiektowo
i korzysta z mechanizmu wyj�tk�w, czego chyba nie da sie powiedzie� o php
- historia bezpiecze�stwa php jest fatalna
--
Wys�ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Krzysztof Stachlewski
> - sensownie zaprojektowane frameworki phpowe s� w nowo�ci�
> i nie umywaj� si� dojrza�o�ci�, dokumentacj� i ilo�ci� dodatk�w do django
Trochďż˝ prawda. Bo samo PHP jest juďż˝ trochďż˝ frameworkiem.
Wi�c ka�dy pisze sobie w�asny.
> - djangowy orm zjada phpowe wymys�y na �niadanie
E tam. Szczerze m�wi�c wol� co� pokroju Doctrine, gdzie mo�na
pisa� w czym� co wygl�da jak SQL, ni� wymy�la�
"jak to b�dzie po djangowemu", chocia� mam w g�owie kwerend�.
No chyba, �eby SqlAlchemy. :-)
> - django ma panel admina
No jaki� ma, ale prawda taka, �e mo�na sobie do�� szybko (tydzie�)
machn�� w�asny w czymkolwiek.
> - python jako j�zyk bardziej zwi�z�y generuje kr�tszy, czytelniejszy i przez
> to �atwiejszy w utrzymaniu kod
Absolutnie prawda!
> - python ma bibliotek� standardow� kt�ra jest zaprojektowana obiektowo
> i korzysta z mechanizmu wyj�tk�w, czego chyba nie da sie powiedzie� o php
Nie da siďż˝ powiedzieďż˝.
> - historia bezpiecze�stwa php jest fatalna
Hmmm... jak si� g�upio w nim pisze, to faktycznie, k�opoty nadchodz�.
Stach
--
http://stachlewski.info
Radomir Dopieralski
Ja bym jeszcze dodal narzedzia i kulture wspierajaca unit testy, oraz
fakt ze nie robi sie w pythonie czegos takiego, ze lapiemy i ignorujemy
wszystkie wyjatki.
--
Radomir Dopieralski, http://sheep.art.pl
Wojciech Malinowski
> Witam.
>
> Powstaje pewien projekt webowy i toczy się dyskusja o technologii.
> Kandydatami są django oraz frameworki phpowe.
> Znam django i osobiście nie mam co do niego wątpliwości
> a w napisanie czytelnego i zarządzalnego kodu w php nie wierzę
> - ale potrzebuję przedstawić to w postaci konkretnych argumentów,
> obejmujących funkcjonalność, jakość frameworków i wszelkie inne
> czynniki mające znaczenie. Wszelkie wypowiedzi, także krytyczne,
> mile widziane.
Osobiście nie znoszę PHP, a bardzo lubię Pythona. Uważam jednak, że
Twoje argumenty są słabe, i że nie przygotowałeś się dobrze do argumentacji.
> - sensownie zaprojektowane frameworki phpowe są w nowością
No i co? O Pythonie każdy może powiedzieć to samo. Czy sensowny jest
Twoim zdaniem Django, czy Pylons, czy Zope?
> i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
Dokumentacja PHP na php.net (z komentarzami) jest jedną z najlepszych
jakie widziałem. O dojrzałości samego PHP w zastosowaniach webowych
chyba nie muszę wspominać, a co do ilości dodatków to dam sobie rękę
uciąć, że różnorakich bibliotek webowych jest więcej w PHP niż Pythonie.
> - djangowy orm zjada phpowe wymysły na śniadanie
O ile dobrze pamiętam to Djangowy ORM to zwykły Active Record. W czym
jest taki szczególny?
> - django ma panel admina
A co go nie ma?
> - python jako język bardziej zwięzły generuje krótszy, czytelniejszy i przez
> to łatwiejszy w utrzymaniu kod
Jedyny moim zdaniem w miarę sensowny argument.
> - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
Ciężko powiedzieć, że biblioteka standardowa została w ogóle w Pythonie
(przynajmniej 2.x) *zaprojektowana*. Ciężko też wykazać jak obiektowość
wpływa na "lepszość" biblioteki, a nawet jak już wykażesz to musisz
potem tłumaczyć czemu pisze się len([]) a nie [].length().
Z argumentem o wyjątkach się zgadzam.
> - historia bezpieczeństwa php jest fatalna
W ogóle nie śledzę więc się nie wypowiem.
Jeżeli chcesz cokolwiek zmienić to zapomnij na chwilę o powyższych
argumentach. Skup się najpierw na tym co jest celem projektu, na tym kto
decyduje o użyciu danej technologii oraz jakie są *konkretne* alternatywy.
1. Cele
Wypunktuj je
2. Osoba decyzyjna
Odpowiedz sobie na pytanie - kim jest, czego oczekuje od wybranej
technologii? Pewnie ważne będą pieniądze pod wieloma postaciami - nie
zapomnij o nich.
3. Alternatywne technologie
Dowiedz się jakie są alternatywy - konkretne nazwy frameworków - a nie
po prostu "frameworki PHPowe". Traktuj każdy z nich z osobna podczas
punktacji.
4. Punktacja
Połącz cele z punktu 1 z oczekiwaniami z punktu 2 i zamień na konkretne
cechy języka/frameworka - to będą wiersze tabeli
Do frameworków z punktu 3 dołącz Django - to będą kolumny
Na przecięciu wpisuj *w miarę obiektywnie* punkty 1-10.
Dodaj ostatni wiersz nazwany "Moja rekomendacja" i daj Django 10 a
reszcie 0.
Podlicz punkty. Jeśli Django wygrało pokaż wszystkim tabelkę - z czymś
takim nie będzie jak dyskutować. Jeżeli Django przegrało to się nie
upieraj i użyj najlepszego narzędzia dla danego problemu albo znajdź
sobie inny projekt.
PS. Przedstawiając swoje propozycje używaj tzw. języka korzyści. Dowiedz
się czym się różni korzyść od cechy.
Pozdrawiam,
Wojciech Malinowski
William Bonawentura
U�ytkownik <sze...@WYTNIJ.gazeta.pl> napisa� w wiadomo�ci
news:h83in7$rl3$1...@inews.gazeta.pl...
> Witam.
>
> Powstaje pewien projekt webowy i toczy siďż˝ dyskusja o technologii.
> Kandydatami sďż˝ django oraz frameworki phpowe.
Technologia to nie wszystko. Wa�ny jest jeszcze zesp�. Argument "python
jako j�zyk bardziej zwi�z�y generuje kr�tszy, czytelniejszy i przez to
�atwiejszy w utrzymaniu kod" �atwo obali� przez "kod php rozumiej� wszyscy,
pythona nieliczni". Za "python ma bibliotek� standardow�" mo�na
przeciwstawi� "do php na ka�dy temat znajd� gotowca w necie i wklej�".
Adam Przybyla
> Witam.
>
> Kandydatami są django oraz frameworki phpowe.
> Znam django i osobiście nie mam co do niego wątpliwości
> a w napisanie czytelnego i zarządzalnego kodu w php nie wierzę
> - ale potrzebuję przedstawić to w postaci konkretnych argumentów,
> obejmujących funkcjonalność, jakość frameworków i wszelkie inne
> czynniki mające znaczenie. Wszelkie wypowiedzi, także krytyczne,
> mile widziane.
>
>
> - sensownie zaprojektowane frameworki phpowe są w nowością
> i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
> - djangowy orm zjada phpowe wymysły na śniadanie
> - django ma panel admina
> - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
> - historia bezpieczeństwa php jest fatalna
juz sie w tym nie lapali. Z powazaniem
Adam Przybyla
Bart Ogryczak
> Kandydatami są django oraz frameworki phpowe.
> Znam django i osobiście nie mam co do niego wątpliwości
> a w napisanie czytelnego i zarządzalnego kodu w php nie wierzę
> - ale potrzebuję przedstawić to w postaci konkretnych argumentów,
> obejmujących funkcjonalność, jakość frameworków i wszelkie inne
> czynniki mające znaczenie. Wszelkie wypowiedzi, także krytyczne,
> mile widziane.
>
> Jak dotąd przychodzi mi do głowy to, że:
>
> - sensownie zaprojektowane frameworki phpowe są w nowością
> i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
To akurat bzdura. Np. ZF powstało w 2005, w tym samym roku, kiedy
powstało Django.
> - djangowy orm zjada phpowe wymysły na śniadanie
SQLAlchemy owszem, Djangowy ORM nie. Jak ja mój gust ma poziom
zbliżony do Propela czy Doctrine.
> - python jako język bardziej zwięzły generuje krótszy, czytelniejszy i przez
> to łatwiejszy w utrzymaniu kod
Owszem.
> - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
Prościej: Python jest językiem obiektowym, PHP nie.
> - historia bezpieczeństwa php jest fatalna
Nie zupełnie. Raczej fatalna jest historia bezpieczeństwa *kiepskich*
acz popularnych projektów, typu phpBB czy phpNuke.
Ok, tyle jeśli chodzi o twoje argumenty. Pamiętaj, nie ma nic
gorszego, jak podać argument nieprawdziwy, który łatwo zbić. Po
pierwszym takim argumencie, nikt nawet nie zada sobie trudu poznać
pozostałych.
Co do PHP vs. Python:
Ewidentne przewagi Pythona:
-- PHP -- obiektawy; Python -- obiektowy
-- PHP -- słabo typowany, wewnętrznie wszystko jest stringiem,
totalnie posrane "żąglowanie typami"; Python -- silnie typowany
-- PHP pisany głównie z myślą o mod_php do Apache; Python - jako
standalone, albo do użycia w połączeniu z szybkimi lekkimi serwerami
jak ngnix czy LigHTTPd. (ok, jest PHP-FPM, ale to nie jest oficjalne)
-- PHP -- zero wielowątkowości; CPython -- wątki (ale GIL),
opcjonalnie greenlety
-- PHP -- XML-RPC i SOAP; Python -- praktycznie dowolne programowanie
rozproszone
-- PHP -- namespaces dopiero w 5.3; Python -- moduły
Coś za coś:
-- PHP -- domknięcia (w 5.3); Python -- comprehensions
-- PHP -- genialna dokumentacja on-line; Python -- genialne docstrings
-- PHP -- developerów na pęczki; Python -- dobrych, to ze świecą
szukać
-- PHP -- wsparcie dla connection pool Oracle; Python -- jednolite DB
API 2.0
No i jeszcze ewentualne używanie na serwerze aplikacji:
-- PHP na JVM -- bardzo słaby, ledwo cokolwiek działa, Jython -- dosyć
stabilny
William Bonawentura
U�ytkownik "Bart Ogryczak" <b.ogr...@gmail.com> napisa� w wiadomo�ci
news:d1a2f9a8-49ea-450c...@m38g2000yqd.googlegroups.com...
-- PHP -- wsparcie dla connection pool Oracle; Python -- jednolite DB
API 2.0
cx_Oracle doskonale wspiera pule Oracle.
Jacek Czerwinski
> On Sep 7, 8:17 pm, " " <sze...@WYTNIJ.gazeta.pl> wrote:
>> - python ma bibliotek� standardow� kt�ra jest zaprojektowana obiektowo
>> i korzysta z mechanizmu wyj�tk�w, czego chyba nie da sie powiedzie� o php
>
> Pro�ciej: Python jest j�zykiem obiektowym, PHP nie.
>
>> - historia bezpiecze�stwa php jest fatalna
>
> Nie zupe�nie. Raczej fatalna jest historia bezpiecze�stwa *kiepskich*
> acz popularnych projekt�w, typu phpBB czy phpNuke.
Ale rozw�j j�zyka zygzakiem to ju� tak. Wspania�e u�atwienia wersji N,
kt�re s� traktowane jako g�wno w wersji N+1.
(Mi sie kojarzy z wojskowa komend� "Od prawego i lewego, kr�tkimi
skokami - naprz�d" - kt�ra nalezy wykonac zygzakiem, wybaczcie offtop)
Wrzuci�bym (pozorn�) nadpoda� programers�w php, w wi�kszo�ci swej
�redniej z fatalnymi nawykami (np. cytowane tu wklejenie fragmentu z
netu zamiast systematycznego u�ycia bibliotek, nawyk wynajdywania ko�a
itd, niskie nawyki do organizacji zespolowej). Niestety g�upi manago
tego argumentu nie zrozumie (chyba �e kto� z was przet�umaczy z
technicznego na polskie)
Bart Ogryczak
> Użytkownik "Bart Ogryczak" <b.ogryc...@gmail.com> napisał w wiadomościnews:d1a2f9a8-49ea-450c...@m38g2000yqd.googlegroups.com...
> -- PHP -- wsparcie dla connection pool Oracle; Python -- jednolite DB
> API 2.0
>
> cx_Oracle doskonale wspiera pule Oracle.
Rzeczywiście, niedawno dodali. Ja używałem cx w wersji 4 i tego
jeszcze nie miało.
Jeśli chodzi o cx_Oracle i samo DB API 2.0, to jak dla mnie największą
wadą tegoż, jest to, że funkcje które nie muszą nic zwracać, nie mają
obowiazku zwracać kursora. DB API do np. SQLite można używać jak
fluent interface, ale już cx_Oracle -- nie.
A ja bym chciał zawsze móc pisać np. cusor.execute(sql).fetchone()
Bart Ogryczak
> Ale rozwój języka zygzakiem to już tak. Wspaniałe ułatwienia wersji N,
> które są traktowane jako gówno w wersji N+1.
Bez przesady, większość tych porypanych "ułatwień" to jest w PHP od
czasów, kiedy się jeszcze nazywało Personal Home Page / Forms
Intepreter.
Generalnie języki idzie w dobrym kierunku, choć istotnie strasznie
powoli i opornie. Niemniej te "ułatwienia" są wywalane, a nie
dokładane. Gdyby nie te zaszłości i gdyby używać SPL zamiast
standardowych obiektów, to PHP 5.3 byłoby całkiem znośnym językiem (do
WWW). Choć MSZ, i tak sporo gorszym od Pythona.
Zupełni inną kwestią jest to, że sporo domorosłych łebmajsterów tkwi
mentalne na poziomie jednowarstowego programowania strukturalnego i
używają nadal zabytkowego PHP4.
Bart Ogryczak
- w PHP nie można zrobić np. $v = fun()[$x]; trzeba $tmp = fun(); $v =
$tmp[$x];
- w PHP mając 10-argumentową funkcję ze zdefiniowanymi domyślnymi
wartościami dla wszystkich, nie można zrobić fun(dziesiaty=10), trzeba
fun(1,2,3,4,5,6,7,8,9,10);
Radomir Dopieralski
> Zupełni inną kwestią jest to, że sporo domorosłych łebmajsterów tkwi
> mentalne na poziomie jednowarstowego programowania strukturalnego i
> używają nadal zabytkowego PHP4.
Nie chcialbym znowu wywolywac swietej wojny, ale wydawalo mi sie, ze
Python domkniecia jednak ma, nawet ich uzywalem...
William Bonawentura
> Je�li chodzi o cx_Oracle i samo DB API 2.0, to jak dla mnie najwi�ksz�
> wad� tego�, jest to, �e funkcje kt�re nie musz� nic zwraca�, nie maj�
> obowiazku zwraca� kursora. DB API do np. SQLite mo�na u�ywa� jak
Napisz sobie dy�urny modu� Bart_cx_Oracle i przecia� te metody tak, by
zwraca�y.
Bart Ogryczak
> Użytkownik "Bart Ogryczak" <b.ogryc...@gmail.com> napisał w wiadomościnews:b7ac6e50-5b67-40e5...@c37g2000yqi.googlegroups.com...
>
> > Jeśli chodzi o cx_Oracle i samo DB API 2.0, to jak dla mnie największą
> > wadą tegoż, jest to, że funkcje które nie muszą nic zwracać, nie mają
>
> Napisz sobie dyżurny moduł Bart_cx_Oracle i przeciaż te metody tak, by
> zwracały.
Po pierwsze mi się nie chce (nie mówiąc już o tym, że aktualnie nie
muszę używać Oracle'a), po drugie jak będę musiał innej bazy zgodnej z
DB API użyć, to znów to samo... A wszystko z powodu jednego małego
niedomówienia w DB API 2.0.
Bart Ogryczak
> At Tue, 8 Sep 2009 07:23:40 -0700 (PDT), Bart Ogryczak wrote:
>
> > Zupełni inną kwestią jest to, że sporo domorosłych łebmajsterów tkwi
> > mentalne na poziomie jednowarstowego programowania strukturalnego i
> > używają nadal zabytkowego PHP4.
>
> Nie chcialbym znowu wywolywac swietej wojny, ale wydawalo mi sie, ze
> Python domkniecia jednak ma, nawet ich uzywalem...
Owszem, domknięcia ma, ale po pierwsze nie ma anonimowych funkcji
(lambdą może być tylko wyrażenie). Ok, do obejścia, ale upierdliwe.
Po drugie w PHP przy domknięciach jest taki fajny bajer pt. "use", co
daje ci większą kontrolę na tym które zmienne widzisz i które możesz
modyfikować w domknięciu. To by się pewnie dało załatwić odpowiednim
dekoratorem.
koval
chester
Hehe, ale chyba ka�dy �redni i lepszy PHPowy programista wie, co to
znaczy (i jak jest po hebrajsku "podw�jny dwukropek")
:-)
Poza tym - co to za j�zyk, kt�ry nie mia�by swoich megaudziwnie�...?
chester
Radomir Dopieralski
> koval pisze:
>> Python'a raczej łatwiej debbugować, patrz:
>> http://tiny.pl/hqm5h
>> :)
>
> Hehe, ale chyba każdy średni i lepszy PHPowy programista wie, co to
> znaczy (i jak jest po hebrajsku "podwójny dwukropek")
>:-)
Tylko ze sredni i lepsi programisci php stanowia okolo 0.001% populacji
programistow php.
> Poza tym - co to za język, który nie miałby swoich megaudziwnień...?
Python oczywiscie ;)
pakalk
>
> - sensownie zaprojektowane frameworki phpowe są w nowością
> i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
Bzdura. Wystarczy spojrzeć na Symfony
> - djangowy orm zjada phpowe wymysły na śniadanie
Doctrine, Propel
> - django ma panel admina
Symfony
> - python jako język bardziej zwięzły generuje krótszy, czytelniejszy i przez
> to łatwiejszy w utrzymaniu kod
Kod krótszy nie musi być czytelniejszy
> - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
Mechanizm wyjątków nie czyni jezyka wyjątkowym
> - historia bezpieczeństwa php jest fatalna
Bzdura
Marek Wywiał
> On Sep 7, 7:17 pm, " " <sze...@WYTNIJ.gazeta.pl> wrote:
>
> > Witam.
>
> > Jak dotąd przychodzi mi do głowy to, że:
>
> > - sensownie zaprojektowane frameworki phpowe są w nowością
> > i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
>
> Bzdura. Wystarczy spojrzeć na Symfony
symfony jest wzorowany na django, części są portowane lub kopiowane:
* http://svn.symfony-project.com/branches/1.2/data/web/sf/sf_admin/js/collapse.js
"> On Feb 4, 8:27 am, Fabien POTENCIER <fabien.potenc...@symfony-
> project.com> wrote:
> > Django is just awesome. I think it's the best python framework... and
> > some features of symfony 2.0 are inspired by Django ;-)
> > Fabien "
>
> > - djangowy orm zjada phpowe wymysły na śniadanie
>
> Doctrine, Propel
doctrine prezentuje się lepiej, zaś propel jest bardzo 'wesołym'
softem.
Zdefiniuj sobie model Product i w nim 2 relacje do np Document jako
order_document_id, i financial_document_id
propel wygeneruje ci metody getDocumentRelatedByOrderDocumentId i
getDocumentRelatedByFinanacialDocumentId
na razie super, używasz sobie tych metod w całym sofcie.
Kiedyś jednak relacja do finacial_document_id zmienia sie na n-n i
usuwasz FK. Wtedy propel usłużnie usunie OBIE metody
i stworzy jedną getDocument, która zastąpi
getDocumentRelatedByOrderDocumentId.
Zaś obsługa relacji n-n tez jest porażająca.
>
> > - django ma panel admina
>
> Symfony
symfony nie ma panelu admina, tylko generator do pojedynczych widoków,
bez logowania, bez layoutu, bez operacji grupowych
to sobie musisz sam napisać. W django dostajesz gotową aplikację.
>
> > - python jako język bardziej zwięzły generuje krótszy, czytelniejszy i przez
> > to łatwiejszy w utrzymaniu kod
>
> Kod krótszy nie musi być czytelniejszy
nie musi, ale masz mniej do czytania i mniej miejsc do popełnienia
błędów
>
> > - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> > i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
>
> Mechanizm wyjątków nie czyni jezyka wyjątkowym
wyjątkowym może nie, ale bezpieczniejszym i łatwiejszym w użyciu.
Wole dostać wyjątek, że nie zdefiniowałem zmiennej niż przesłać tą
niezdefiniowaną zmienną
do miliona rekordów w bazie czyszcząc wpisy i dowiedzieć się o tym po
fakcie przeglądając bazę
lub logi z php.
Ew. wykonując connect do ftp w pythonie dostaniesz wyjątki na każdą
okazję, nieprawidłowy host/port user, itp
w php dostaniesz true false, w logach sobie przeczytasz co się stało,
ale co wyświetlić temu klientowi, który użył
twojego webgui i chciałby wiedzieć gdzie popełnił błąd?
>
> > - historia bezpieczeństwa php jest fatalna
>
> Bzdura
niestety nie miałem czasu zapoznać się ze wszystkimi argumentami,
które tu podałeś,
ale po zapoznaniu się z wpisami w changelog'u php zgadzam się z
przedmówcą.
pakalk
> On 28 Paź, 22:04, pakalk <pak...@gmail.com> wrote:
>
> > On Sep 7, 7:17 pm, " " <sze...@WYTNIJ.gazeta.pl> wrote:
>
> > > Witam.
>
> > > Jak dotąd przychodzi mi do głowy to, że:
>
> > > - sensownie zaprojektowane frameworki phpowe są w nowością
> > > i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
>
> > Bzdura. Wystarczy spojrzeć na Symfony
>
> symfony jest wzorowany na django, części są portowane lub kopiowane:
1. co z tego?
2. nie tylko na django
3. nie zmienia to faktu, ze symfony jest dobry
>
> "> On Feb 4, 8:27 am, Fabien POTENCIER <fabien.potenc...@symfony-
>
> > project.com> wrote:
> > > Django is just awesome. I think it's the best python framework... and
> > > some features of symfony 2.0 are inspired by Django ;-)
> > > Fabien "
>
> > > - djangowy orm zjada phpowe wymysły na śniadanie
>
> > Doctrine, Propel
>
> doctrine prezentuje się lepiej, zaś propel jest bardzo 'wesołym'
> softem.
zgoda
> Zdefiniuj sobie model Product i w nim 2 relacje do np Document jako
> order_document_id, i financial_document_id
> propel wygeneruje ci metody getDocumentRelatedByOrderDocumentId i
> getDocumentRelatedByFinanacialDocumentId
> na razie super, używasz sobie tych metod w całym sofcie.
>
> Kiedyś jednak relacja do finacial_document_id zmienia sie na n-n i
> usuwasz FK. Wtedy propel usłużnie usunie OBIE metody
> i stworzy jedną getDocument, która zastąpi
> getDocumentRelatedByOrderDocumentId.
>
> Zaś obsługa relacji n-n tez jest porażająca.
ok
>
>
>
> > > - django ma panel admina
>
> > Symfony
>
> symfony nie ma panelu admina, tylko generator do pojedynczych widoków,
> bez logowania, bez layoutu, bez operacji grupowych
> to sobie musisz sam napisać. W django dostajesz gotową aplikację.
>
>
>
> > > - python jako język bardziej zwięzły generuje krótszy, czytelniejszy i przez
> > > to łatwiejszy w utrzymaniu kod
>
> > Kod krótszy nie musi być czytelniejszy
>
> nie musi, ale masz mniej do czytania i mniej miejsc do popełnienia
> błędów
>
nie do konca prawda:
- mniej do czytania - tak
- mniej miejsc - nie
>
>
> > > - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> > > i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
>
> > Mechanizm wyjątków nie czyni jezyka wyjątkowym
>
> wyjątkowym może nie, ale bezpieczniejszym i łatwiejszym w użyciu.
> Wole dostać wyjątek, że nie zdefiniowałem zmiennej niż przesłać tą
> niezdefiniowaną zmienną
> do miliona rekordów w bazie czyszcząc wpisy i dowiedzieć się o tym po
> fakcie przeglądając bazę
> lub logi z php.
set_error_handler()
set_exception_handler()
>
> Ew. wykonując connect do ftp w pythonie dostaniesz wyjątki na każdą
> okazję, nieprawidłowy host/port user, itp
> w php dostaniesz true false, w logach sobie przeczytasz co się stało,
> ale co wyświetlić temu klientowi, który użył
> twojego webgui i chciałby wiedzieć gdzie popełnił błąd?
z FTP to prawda - w PHP nie ma dobrej obslugi - ostatnio pisalem
(modyfikowalem) klase laczaca sie po socketach - inaczej nie idzie
tego zrobic
>
> > > - historia bezpieczeństwa php jest fatalna
>
> > Bzdura
>
> niestety nie miałem czasu zapoznać się ze wszystkimi argumentami,
> które tu podałeś,
> ale po zapoznaniu się z wpisami w changelog'u php zgadzam się z
> przedmówcą.
Co ja mam tu argumentowac? Jak ktos powie, ze Ziemia ma 8 księżyców,
tez mam argumentowac, ze to bzdura?
pakalk
>
> > i nie umywają się dojrzałością, dokumentacją i ilością dodatków do django
>
> Dokumentacja PHP na php.net (z komentarzami) jest jedną z najlepszych
> jakie widziałem. O dojrzałości samego PHP w zastosowaniach webowych
> chyba nie muszę wspominać, a co do ilości dodatków to dam sobie rękę
> uciąć, że różnorakich bibliotek webowych jest więcej w PHP niż Pythonie.
Dokumentacja rzeczywiscie niezla.
Reki natomiast bym nie dawal uciac - co z tego, ze w PHP jest masa
bibliotek, skoro nie ma np. do FTP, a jakosc jest mierna (bo po co
pisac, jak jest - guzik warte, ale jest)
>
> > - python ma bibliotekę standardową która jest zaprojektowana obiektowo
> > i korzysta z mechanizmu wyjątków, czego chyba nie da sie powiedzieć o php
>
> Ciężko powiedzieć, że biblioteka standardowa została w ogóle w Pythonie
> (przynajmniej 2.x) *zaprojektowana*. Ciężko też wykazać jak obiektowość
> wpływa na "lepszość" biblioteki, a nawet jak już wykażesz to musisz
> potem tłumaczyć czemu pisze się len([]) a nie [].length().
Wlasnie to mnie dziwi. Czemu jest len() a nie .length()?
> 3. Alternatywne technologie
> Dowiedz się jakie są alternatywy - konkretne nazwy frameworków - a nie
> po prostu "frameworki PHPowe". Traktuj każdy z nich z osobna podczas
> punktacji.
..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to nie jest
taki zly ten pehap.
Marek Wywiał
> ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to nie jest
> taki zly ten pehap.
Tu się zgadzam.
Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy tutorial,
var_dump i 1-2 lata klepania szablonów w php (nie aplikacji).
Ilość kruczków, magii słabego typowania, czy niekompatybilności w
wersjach minor lub obsługi (raczej brak) unicode/itp, sporadyczne/
losowe sigfault'y
i ogrom cieknącej pamięci + wiele więcej, wymaga:
* wiedzy, że to cie może spotkać
* wiedzy, jak z tym żyć
czego większość użytkowników PHP nie wie.
W symfony wycieki, limity czasu działania obchodzone są przez cache i
generator. Niestety PHP tak łatwo się nie da i przy większych
projektach + dużym obciążeniu cache rośnie w tempie ok 1GB/2h. Symfony
ma wbudowane czyszczenie plików z cache po pewnym czasie ale usuwa je
pojedynczo nie zauważając, że przy generowaniu ich tworzy pliki cache
zależne, więc ok 10 razy dziennie soft kończy z error500, i należy
wykonać ręcznie ./symfony cc, a raczej 'mv cache cache.old;mkdir
cache; chmod cache 777;' bo ./symfony cc przy takim cache trwa ok 2
godzin, a soft leży.
PHP ma dobra dokumentację bo musi mieć, chaos w nazwach i parametrach
(zwłaszcza ich kolejności) jest niewiarygodny i ja nie jestem tego w
stanie zapamiętać
przez ostatnie ~9lat :)
więc wracając do wypowiedzi, w php da się zrobić soft i trzeba podejść
do tego poważnie i z poważnymi ludźmi.
pakalk
> On 29 Paź, 14:05, pakalk <pak...@gmail.com> wrote:
>
> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to nie jest
> > taki zly ten pehap.
>
> Tu się zgadzam.
>
> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy tutorial,
> var_dump i 1-2 lata klepania szablonów w php (nie aplikacji).
Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli, a nie
jezyk.
>
> W symfony wycieki, limity czasu działania obchodzone są przez cache i
> generator. Niestety PHP tak łatwo się nie da i przy większych
> projektach + dużym obciążeniu cache rośnie w tempie ok 1GB/2h. Symfony
> ma wbudowane czyszczenie plików z cache po pewnym czasie ale usuwa je
> pojedynczo nie zauważając, że przy generowaniu ich tworzy pliki cache
> zależne, więc ok 10 razy dziennie soft kończy z error500, i należy
> wykonać ręcznie ./symfony cc, a raczej 'mv cache cache.old;mkdir
> cache; chmod cache 777;' bo ./symfony cc przy takim cache trwa ok 2
> godzin, a soft leży.
>
> PHP ma dobra dokumentację bo musi mieć, chaos w nazwach i parametrach
No nie przesadzajmy, ze ma dobra dokumentacje, bo ma chaos.
> (zwłaszcza ich kolejności) jest niewiarygodny i ja nie jestem tego w
> stanie zapamiętać
Ja ciagle zagladam do podstawowych funkcji typu array_*(), bo nigdy
nie wiem, czy ta tablica przekazana jest jako pierwszy czy niepierwszy
argument.
>
> więc wracając do wypowiedzi, w php da się zrobić soft i trzeba podejść
> do tego poważnie i z poważnymi ludźmi.
Otoz to.
----
PHP jednak nie jest ogolnego zastosowania, jak sie mniema - gry w nim
sie nie zrobi. Dlatego przerzucam sie na pythona :P Albo Javę.
Grzegorz Staniak
>> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to nie
>> > jest taki zly ten pehap.
>>
>> Tu się zgadzam.
>>
>> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy tutorial,
>> var_dump i 1-2 lata klepania szablonów w php (nie aplikacji).
>
> Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli,
> a nie jezyk.
Język niezależnie od wszystkiego innego też jest zdrowo skopany.
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing
pakalk
> On 29.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to nie
> >> > jest taki zly ten pehap.
>
> >> Tu się zgadzam.
>
> >> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy tutorial,
> >> var_dump i 1-2 lata klepania szablonów w php (nie aplikacji).
>
> > Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli,
> > a nie jezyk.
>
> Język niezależnie od wszystkiego innego też jest zdrowo skopany.
>
To znaczy? Co konkretnie?
Exe Very Cute
>>
>
> To znaczy? Co konkretnie?
1. Jest powooolny
2. Wynalazki typu safe_mode czy magic_quotes
3. Niejednorodna sk�adnia i kolejno�� parametr�w funkcji (co sam
wspomnia�e�)
4. Jest powooolny
5. Jest powooolny
6. K�opoty nawet przy obs�udze du�ych liczb (potrzebne biblioteki)
7. PHP jest od pocz�tku tworzony jako j�zyk 'webowy' - dam przyk�ad 'z
�ycia' - kiedy nagle trzeba do softu pod��czy� kas� fiskaln� na USB i
napisanie aplikacji klienckiej to zaczyna siďż˝ problem
8. Po tych 8 czy 9 latach rzygam nim
Szczeg�lnie punkty 1,4, 5 oraz 7 i 8 maj� wp�yw na to �e przesiadam si�
na Pythona. Nie mam d�u�ej ochoty bawi� si� w cache tam gdzie nie
powinienem i bujaďż˝ siďż˝ z tworzeniem .so/.dll.
Pozdr
Exe Very Cute
Grzegorz Staniak
>> >> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to
>> >> > nie jest taki zly ten pehap.
>>
>> >> Tu się zgadzam.
>>
>> >> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy
>> >> tutorial, var_dump i 1-2 lata klepania szablonów w php (nie
>> >> aplikacji).
>>
>> > Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli, a
>> > nie jezyk.
>>
>> Język niezależnie od wszystkiego innego też jest zdrowo skopany.
>
> To znaczy? Co konkretnie?
Lepiej zapytaj co nie zostało skopane. Tysiące wbudowanych funkcji
w jednej przestrzeni nazw to po prostu chory sen wariata, niespójne
nazewnictwo i kolejność argumentów pogłębiają to wrażenie. Fatalna
obsługa unikodu i ogólnie kodowań tekstu. Obsługa błędów po prostu
tragiczna, przy zagnieżdżonych inkludach błąd na kolejnym poziomie
zagnieżdżenia produkuje biały ekran i tyle. Pierdyliard niespójności
i zagwozdek semantycznych, jak słynne '(string)"false" == (int)0 is true'.
Wymóżdżone typy danych, jak "lista i hasz w jednym", nie dająca
w sumie ani dobrego hasza, ani dobrej listy (niespójność indeksów
po usunięciu elementu ze środka listy to kuriozum), albo int, którego
rozmiaru nigdy nie możesz być pewien (32-bit na systemach 32-bit,
64-bit na 64-bitowych), tak samo jak tego, że zostanie zwrócony jako
unsigned. Pseudo-referencje. OOP jako afterthought, ledwo doprowadzone
do używalności w PHP 5. Brak thread-safety. Tę listę naprawde można
by jeszcze sporo przedłużyć.
pakalk
> pakalk pisze:
>
> > On Oct 29, 3:44 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> > To znaczy? Co konkretnie?
>
> 1. Jest powooolny
Nie ma zwiazku z jezykiem, tylko implementacja. Poza tym nie jest
wcale tak wolny.
> 2. Wynalazki typu safe_mode czy magic_quotes
z PHP3, a mamy PHP5.3
> 7. PHP jest od początku tworzony jako język 'webowy' - dam przykład 'z
> życia' - kiedy nagle trzeba do softu podłączyć kasę fiskalną na USB i
> napisanie aplikacji klienckiej to zaczyna się problem
Raczej rzadko sie podlacza kasy fiskalne do stron internetowych, ale
moze sie nie znam :P
pakalk
> On 29.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> >> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to
> >> >> > nie jest taki zly ten pehap.
>
> >> >> Tu się zgadzam.
>
> >> >> Żeby napisać dużą i dobrą aplikację w PHP nie wystarczy
> >> >> tutorial, var_dump i 1-2 lata klepania szablonów w php (nie
> >> >> aplikacji).
>
> >> > Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli, a
> >> > nie jezyk.
>
> >> Język niezależnie od wszystkiego innego też jest zdrowo skopany.
>
> > To znaczy? Co konkretnie?
>
> Lepiej zapytaj co nie zostało skopane. Tysiące wbudowanych funkcji
> w jednej przestrzeni nazw to po prostu chory sen wariata,
Bo nie było do tej pory przestrzeni.
> niespójne
> nazewnictwo i kolejność argumentów pogłębiają to wrażenie.
> Fatalna
> obsługa unikodu i ogólnie kodowań tekstu.
> Obsługa błędów po prostu
> tragiczna, przy zagnieżdżonych inkludach błąd na kolejnym poziomie
> zagnieżdżenia produkuje biały ekran i tyle. Pierdyliard niespójności
> i zagwozdek semantycznych, jak słynne '(string)"false" == (int)0 is true'.
> Wymóżdżone typy danych, jak "lista i hasz w jednym"
Co akurat wadą nie jest, bo niby czemu? Poza tym nie ma czegos takiego
jak lista w typach wbudowanych w PHP. Uznaje, ze chodzilo Ci o
tablice.
> , nie dająca
> w sumie ani dobrego hasza, ani dobrej listy (niespójność indeksów
> po usunięciu elementu ze środka listy to kuriozum),
Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone, a jesli
chodzi o struktury danych...
http://www.php.net/manual/en/spl.datastructures.php
> albo int, którego
> rozmiaru nigdy nie możesz być pewien (32-bit na systemach 32-bit,
> 64-bit na 64-bitowych),
No to mozesz byc pewien: 32 na 32, 64 na 64 :>
> tak samo jak tego, że zostanie zwrócony jako
> unsigned.
> Pseudo-referencje.
Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne referencje.
> OOP jako afterthought, ledwo doprowadzone
> do używalności w PHP 5.
Prosze Cie..
> Brak thread-safety. Tę listę naprawde można
> by jeszcze sporo przedłużyć.
>
Moze i mozna, ale polowa tej listy to wymysly bez pokrycia w faktach.
Czesciowo to tez wina implementacji - nie jezyka.
Grzegorz Staniak
>> >> Język niezależnie od wszystkiego innego też jest zdrowo
>> >> skopany.
>>
>> > To znaczy? Co konkretnie?
>>
>> Lepiej zapytaj co nie zostało skopane. Tysiące wbudowanych
>> funkcji w jednej przestrzeni nazw to po prostu chory sen wariata,
>
> Bo nie było do tej pory przestrzeni.
Ale ja nie mówię o tym co obecni autorzy wiedzą że powinno być
i co planują, czy powoli wprowadzają, ale o tym co było i co
jest -- i jeszcze będzie, ze względu na zgodność w dół.
>> niespójne nazewnictwo i kolejność argumentów pogłębiają to
>> wrażenie. Fatalna obsługa unikodu i ogólnie kodowań tekstu.
>> Obsługa błędów po prostu tragiczna, przy zagnieżdżonych
>> inkludach błąd na kolejnym poziomie zagnieżdżenia produkuje
>> biały ekran i tyle. Pierdyliard niespójności i zagwozdek
>> semantycznych, jak słynne '(string)"false" == (int)0 is true'.
>> Wymóżdżone typy danych, jak "lista i hasz w jednym"
>
> Co akurat wadą nie jest, bo niby czemu?
Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
Podpowiedź: wydajność.
>> , nie dająca w sumie ani dobrego hasza, ani dobrej listy
>> (niespójność indeksów po usunięciu elementu ze środka listy
>> to kuriozum),
>
> Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
Przez kogo konkretnie? Decyzja o zrobieniu listy-i-hasza jako
mapującej struktury danych jest po prostu debilna. Poza PHP
robi to chyba tylko AWK. Dzięki temu masz strukturę powolną
jak diabli, ale za to pozbawioną zalet listy: jeśli po usunięciu
indeksu muszę używać funkcji żeby indeksy zachowały ciągłość:
$array = array_values($array);
to coś jest grubo nie tak. Kto konkretnie chwali te tablice
i za co, jeśli można wiedzieć?
> a jesli chodzi o struktury danych...
>
> http://www.php.net/manual/en/spl.datastructures.php
To, że musisz sobie z czasem sztukować funkcjonalność rozszerzeniami
(np. bcmath, żeby można było polegać na integerach) potwierdza tylko
tezę o błędach w projekcie języka. Nie jest żadną wielką chwałą, że
po latach PHP dorobiło się struktur znanych dawno z innych języków.
>> albo int, którego rozmiaru nigdy nie możesz być pewien (32-bit
>> na systemach 32-bit, 64-bit na 64-bitowych),
>
> No to mozesz byc pewien: 32 na 32, 64 na 64 :>
Mało śmieszne, kiedy żeby być pewnym działania aplikacji musisz
używać rozszerzeń naprawiających te błędne decyzje projektowe,
albo pisać własne wrappery sprawdzające, czy na pewno nie strzelasz
sobie w stopę. I pamiętać, żeby użyć ich wszędzie tam, gdzie może
pojawić się kłopot.
>> tak samo jak tego, że zostanie zwrócony jako unsigned.
>
>> Pseudo-referencje.
>
> Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne
> referencje.
To są aliasy, nie referencje (w PHP poniżej 5).
>> OOP jako afterthought, ledwo doprowadzone do używalności w PHP 5.
>
> Prosze Cie..
O co?
>> Brak thread-safety. Tę listę naprawde można by jeszcze sporo
>> przedłużyć.
>
> Moze i mozna, ale polowa tej listy to wymysly bez pokrycia w
> faktach.
Sorki, ale nie masz pojęcia o czym mówisz. Używam PHP od wersji
0.8, koło 15 lat, i zdążył mi już przejść zachwyt nad tym jakie
to wspaniałe środowisko.
Exe Very Cute
> On Oct 29, 9:19 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
>> pakalk pisze:
>>
>>> On Oct 29, 3:44 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
>>> To znaczy? Co konkretnie?
>> 1. Jest powooolny
>
> Nie ma zwiazku z jezykiem, tylko implementacja. Poza tym nie jest
> wcale tak wolny.
�e co?
>> 2. Wynalazki typu safe_mode czy magic_quotes
>
> z PHP3, a mamy PHP5.3
No w�a�nie, tym gorzej. Bo te bzdury nadal obowi�zuj�. Pisz�c skrypt w
5.3 nadal musisz sprawdza� czy magic_quotes czy safe_mode s� w��czone!
>> 7. PHP jest od pocz�tku tworzony jako j�zyk 'webowy' - dam przyk�ad 'z
>> �ycia' - kiedy nagle trzeba do softu pod��czy� kas� fiskaln� na USB i
>> napisanie aplikacji klienckiej to zaczyna siďż˝ problem
>
> Raczej rzadko sie podlacza kasy fiskalne do stron internetowych, ale
> moze sie nie znam :P
Chyba nie zrozumia�e� :-/ W�a�nie o tym pisz� - PHP jest mocno
ukierunkowany, przez co nie daje siďż˝ w nim pisaďż˝ aplikacji innych nie
webowe, wi�c nie jeste� w stanie napisa� w PHP pe�nej aplikacji - mo�esz
napisa� cze�� webow� - w PHP, a do obs�ugi kasy fiskalnej musisz wybra�
inny j�zyk. W Pythonie mog� mie� napisane od A do Z wszystko.
Pozdr
Exe Very Cute
pakalk
> pakalk pisze:
>
> > On Oct 29, 9:19 pm, Exe Very Cute <ksh...@poczta.Xonet.pl> wrote:
> >> pakalk pisze:
>
> >>> On Oct 29, 3:44 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> >>> To znaczy? Co konkretnie?
> >> 1. Jest powooolny
>
> > Nie ma zwiazku z jezykiem, tylko implementacja. Poza tym nie jest
> > wcale tak wolny.
>
Nie rozumiem. Dziwisz się, ze mowie, ze nie taki znowu wolny? No nie
jest :) Chociaz ok, mozliwe, ze jest wolniejszy od Pythona, a raczej
jego implementacji.
>
> >> 2. Wynalazki typu safe_mode czy magic_quotes
>
> > z PHP3, a mamy PHP5.3
>
> No właśnie, tym gorzej. Bo te bzdury nadal obowiązują. Pisząc skrypt w
> 5.3 nadal musisz sprawdzać czy magic_quotes czy safe_mode są włączone!
Owszem. Tylko nie sa to elementy, ktorych sie nie da wylaczyc,
standardowo sa wylaczane, a w przyszlosci znikna zupelnie. W pythonie
nie ma zadnych zaszlosci?
>
> >> 7. PHP jest od początku tworzony jako język 'webowy' - dam przykład 'z
> >> życia' - kiedy nagle trzeba do softu podłączyć kasę fiskalną na USB i
> >> napisanie aplikacji klienckiej to zaczyna się problem
>
> > Raczej rzadko sie podlacza kasy fiskalne do stron internetowych, ale
> > moze sie nie znam :P
>
> Chyba nie zrozumiałeś :-/ Właśnie o tym piszę - PHP jest mocno
> ukierunkowany, przez co nie daje się w nim pisać aplikacji innych nie
> webowe,
Nie do konca, bo skryptowo tez sobie radzi.
> więc nie jesteś w stanie napisać w PHP pełnej aplikacji -
Zalezy czym jest 'pelna aplikacja'. PHP przeznaczony jest do pisania
stron, ale moze byc uzywany takze jako jezyk ogolnego zastosowania w
ograniczonym bibliotekami stopniu. Niestety to one decyduja (a moze
stety). Ciezko winic jednak PHP za to, ze nie da sie nim robic rzeczy
do ktorych nie zostal stworzony.
> możesz
> napisać cześć webową - w PHP, a do obsługi kasy fiskalnej musisz wybrać
> inny język.
Nie do konca to prawda, bo czytniki kodow kreskowych napisane w PHP
istnieja. Fakt jednak, ze:
1. jest ciezko
2. PHP nie kojarzy sie z takimi zastosowaniami
> W Pythonie mogę mieć napisane od A do Z wszystko.
Rzeczywiscie biblioteki sa bogatsze, jesli chodzi o zakres zagadnien.
pakalk
> Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
> Podpowiedź: wydajność.
Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
strukturze. Posiada tablice asocjacyjne.
>
> > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>
> Przez kogo konkretnie?
Przez wiele osob.
> Decyzja o zrobieniu listy-i-hasza jako
> mapującej struktury danych jest po prostu debilna.
Nic takiego nie ma miejsca. Nie wiem, ale moze nie bez powodu to sie
nazywa array a nie list? Nie uwazasz?
> Poza PHP
> robi to chyba tylko AWK. Dzięki temu masz strukturę powolną
> jak diabli, ale za to pozbawioną zalet listy: jeśli po usunięciu
> indeksu muszę używać funkcji żeby indeksy zachowały ciągłość:
>
> $array = array_values($array);
Pewnie dlatego, ze to nie jest tablica indeksowana 0..n tylko tablica
asocjacyjna klucz=>wartosc - to, ze jest to lista, to juz Twoj wymysl.
Dziwne by bylo tez, gdyby zachowywalo sie to inaczej dla roznych typow
indeksow.
>
> to coś jest grubo nie tak. Kto konkretnie chwali te tablice
> i za co, jeśli można wiedzieć?
>
> > a jesli chodzi o struktury danych...
>
> >http://www.php.net/manual/en/spl.datastructures.php
>
> To, że musisz sobie z czasem sztukować funkcjonalność rozszerzeniami
Jakie rozszwrzenie? Standard PHP Library - to sie tak nazywa.
Krytykujesz array_*(), ktore sa tak samo w dystrybucji jak SPL. W
Javie na przyklad tez nie widze, aby chocby tablice asocjacyjne byly
wbudowane i co z tego?
>
> >> Pseudo-referencje.
>
> > Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne
> > referencje.
>
> To są aliasy, nie referencje (w PHP poniżej 5).
Czemu mamy rozmawiac o czyms, co juz nie jest nawet przez Zenda
wspierane?! Moze pogadajmy o 'classic-style classes', albo pythonie
1.0? Taki doskonaly byl?
I tak - w PHP sa 'aliasy', ktore sa wybitnie przydatne jak pointery w C
++. Ale obok tez funkcjonuja (tak, od PHP5, ale PHP5 wprowadzono juz
dawno temu) referencje, ktore dzialaja jak te javowe - nie widze
powodu do narzekania!
>
> >> OOP jako afterthought, ledwo doprowadzone do używalności w PHP 5.
>
> > Prosze Cie..
>
> O co?
Nie rozumiem krytyki OOP - moze konkrety?
Marek Wywiał
>
> > Chyba nie zrozumiałeś :-/ Właśnie o tym piszę - PHP jest mocno
> > ukierunkowany, przez co nie daje się w nim pisać aplikacji innych nie
> > webowe,
>
> Nie do konca, bo skryptowo tez sobie radzi.
Przykład: aplikacja www (php5) e-commerce zawierająca bazę ok 300k
produktów, posiadających odpowiedniki np w 3 magazynach czyli + 900k
wpisów,
logika zamknięta w Propel (Peer), więc żeby logiki nie dublować
skrypt analizujące ceny i stany magazynowe jest też w php5 uruchamiany
z shell'a (cron).
Robi to ok 5-6h na maszynie 4core, 8GB ramu, zużywając samemu ponad
512MB ramu, przy przetwarzaniu sekwencyjnym:
* po 1 robi to wolno dlatego tyle czasu jedzie
* po 2 cieknie wszędzie;
po kompilacji php5.2.6 w trybie debug i wykonaniu F5 na prostym widoku
symfony, debug zgłasza 20k-30k memory leaks detected.
Reasumując w/g mnie skryptowo sobie nie radzi. A jeżeli miałbym go
użyć do prostszych skryptów nie używających logiki mojej aplikacji to
szybszy (w działani i pisaniu) będzie bash.
Skoro skrypty mam pisać w innym języku, a skrypt ma współdzielić
logikę z inną częścią softu, lepsze jest język pozwalający mi sprawnie
utworzyć obie części (co już było wspominane na tym wątku
wielokrotnie).
>
Radomir Dopieralski
>> >> 2. Wynalazki typu safe_mode czy magic_quotes
>> > z PHP3, a mamy PHP5.3
>> No właśnie, tym gorzej. Bo te bzdury nadal obowiązują. Pisząc skrypt w
>> 5.3 nadal musisz sprawdzać czy magic_quotes czy safe_mode są włączone!
> Owszem. Tylko nie sa to elementy, ktorych sie nie da wylaczyc,
> standardowo sa wylaczane, a w przyszlosci znikna zupelnie. W pythonie
> nie ma zadnych zaszlosci?
Wszystko w porzadku jak piszesz program dla siebie, ktory wrasta sobie
w twoj serwer i nigdy nie bedzie na niczym innym instalowany. Nieco
gorzej jest kiedy piszesz program, ktory chcesz dac ludziom do sciagniecia
i zainstalowania -- musisz dolaczyc instrukcje jak skonfigurowac do niego
interpreter. Kompletna klapa jesli chcesz napisac program na zasadzie
"rozpakuj i dziala" -- albo przewidujesz i obslugujesz wszystkie mozliwe
konfiguracje, albo po prostu wybierasz jedna najpopularniejsza i olewasz
wszystkich innych uzytkownikow.
W pythonie jest o tyle prosciej, ze po prostu wymagasz co najmniej jakiejs
tam wersji interpretera i bibliotek i wiesz na czym stoisz. Nawet jesli
ktos wpadnie na pomysl zrobienia konfigurowalnej biblioteki, to wrzucasz
ja po prostu do swojego programu w calosci juz pod niego skonfigurowana.
Marek Wywiał
> On Oct 30, 12:10 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> > Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
> > Podpowiedź: wydajność.
>
> Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
> strukturze. Posiada tablice asocjacyjne.
>
>
>
> > > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>
> > Przez kogo konkretnie?
>
> Przez wiele osob.
Dość enigmatyczne stwierdzenie.
Osobiście słyszałem 2 razy, by ktoś chwalił mix list/hash z php. Raz
na grupie goldenline (nie pamiętam kto, ale argumenty nie były silne)
i teraz Ty.
PHP jest sprytniejszy od przeciętnego programisty i sam ci
przenumeruje twoje klucze na indexy, lub odwrotnie.
Zbierz sobie w array dane cena produktu => ilość wystąpień np
<?php
$a = array(
1 => 13,
2 => 16,
2.29 => 17,
3 => 20,
3.14 => 23,
);
var_dump($a);
+ zalety słabego typowania:
$a = array('bolek','lolek',0,'tola');
var_dump(in_array('reksio', $a));
i reksio ożywa
czy inny przypadek literówki + słabe typowanie:
<?php
error_reporting(E_ALL);
$ciag = "";
$ciag[] .= 'Jezu';
$ciag[] .= 'Chryste';
var_dump($ciag);
'obsługa' dat jest cudowna, wystawmy sobie fakturkę
<?php
$t = '2003/02/30';
var_dump(strtotime($t));
radość księgowej - bezcenna
i czym jest naprawdę static method
<?php
class B
{
public function rzyc()
{
$this->Atam();
}
}
class A
{
public function test()
{
B::rzyc();
}
public function Atam()
{
var_dump('A TAM');
}
}
$a = new A;
$a->test();
wszystkie te przykłady sa wynikiem długiego debuggowania softu, który
nie zgłasza problemów - tylko nie działa
pakalk
> On 30 Paź, 08:12, pakalk <pak...@gmail.com> wrote:
>
>
>
> > > Chyba nie zrozumiałeś :-/ Właśnie o tym piszę - PHP jest mocno
> > > ukierunkowany, przez co nie daje się w nim pisać aplikacji innych nie
> > > webowe,
>
> > Nie do konca, bo skryptowo tez sobie radzi.
>
> Przykład: aplikacja www (php5) e-commerce zawierająca bazę ok 300k
> produktów, posiadających odpowiedniki np w 3 magazynach czyli + 900k
> wpisów,
W koncu jakis konkret ;)
Tylko to chyba wina propela moze byc, nie samego PHP. Ale, whatever...
skryptowo mimo wszystko sobie radzi ;) I w bashu raczej glupio pisac
cos, co mozna oprzec o klasy gotowej aplikacji...
pakalk
> At Fri, 30 Oct 2009 00:12:40 -0700 (PDT), pakalk wrote:
>
> >> >> 2. Wynalazki typu safe_mode czy magic_quotes
> >> > z PHP3, a mamy PHP5.3
> >> No właśnie, tym gorzej. Bo te bzdury nadal obowiązują. Pisząc skrypt w
> >> 5.3 nadal musisz sprawdzać czy magic_quotes czy safe_mode są włączone!
> > Owszem. Tylko nie sa to elementy, ktorych sie nie da wylaczyc,
> > standardowo sa wylaczane, a w przyszlosci znikna zupelnie. W pythonie
> > nie ma zadnych zaszlosci?
>
> Wszystko w porzadku jak piszesz program dla siebie, ktory wrasta sobie
> w twoj serwer i nigdy nie bedzie na niczym innym instalowany. Nieco
> gorzej jest kiedy piszesz program, ktory chcesz dac ludziom do sciagniecia
> i zainstalowania -- musisz dolaczyc instrukcje jak skonfigurowac do niego
> interpreter. Kompletna klapa jesli chcesz napisac program na zasadzie
> "rozpakuj i dziala" -- albo przewidujesz i obslugujesz wszystkie mozliwe
> konfiguracje, albo po prostu wybierasz jedna najpopularniejsza i olewasz
> wszystkich innych uzytkownikow.
Dranie z tych producentrow gier - na kazdym pudelku jest napisana
konfiguracja minimalna do odpalenia gry. A co jakbym chcial na swoim
486 - nie zaziala... kurde!
Serio: wymagania aplikacji chyba jakies sa - nie dziala w prozni. Jak
ktos nie umie sobie skonfigurowac, to nie umie. A jesli my chcemy cos
wymusic, to mozemy przez htaccess chocby.
>
> W pythonie jest o tyle prosciej, ze po prostu wymagasz co najmniej jakiejs
> tam wersji interpretera i bibliotek i wiesz na czym stoisz. Nawet jesli
> ktos wpadnie na pomysl zrobienia konfigurowalnej biblioteki, to wrzucasz
> ja po prostu do swojego programu w calosci juz pod niego skonfigurowana.
>
Szczegolnie proste bedzie przejscie na pythona 3 z podstawowym
printem ;)
Ale ok - jest moze prosciej. Tylko nie chodzi mi o to gdzie jest
prosciej, ale o to, ze argument jest nietrafiony.
Grzegorz Staniak
>> Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
>> Podpowiedź: wydajność.
>
> Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
> strukturze. Posiada tablice asocjacyjne.
Sprawdź sobie, jak działa 'array'. Ze szczególnym uwzględnieniem
składni udającej listy.
>> > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>>
>> Przez kogo konkretnie?
>
> Przez wiele osob.
A konkretnie? Kto i za co je chwali? Przejdź się na dowolny wydział
informatyki, zapytaj ludzi od struktur danych. Jeśli usłyszysz
pochwały, daj znać -- to będą chyba pierwsze jakie PHP od nich
dostanie.
>> Decyzja o zrobieniu listy-i-hasza jako mapującej struktury danych
>> jest po prostu debilna.
>
> Nic takiego nie ma miejsca.
Sorki, ale nie masz pojęcia o czym mówisz. Sprawdź sobie jak jest
implementowane 'array' i zastanów się, dlaczego składniowo udaje
również listę.
[...]
>> Poza PHP robi to chyba tylko AWK. Dzięki temu masz strukturę
>> powolną jak diabli, ale za to pozbawioną zalet listy: jeśli po
>> usunięciu indeksu muszę używać funkcji żeby indeksy zachowały
>> ciągłość:
>>
>> $array = array_values($array);
>
> Pewnie dlatego, ze to nie jest tablica indeksowana 0..n tylko
> tablica asocjacyjna klucz=>wartosc - to, ze jest to lista, to juz
> Twoj wymysl.
Składniowo udaje listę, prawda? Normalny hasz nie pozwala na
deklarowanie go np. jako '$array = array("a", "b", "c");'.
> Dziwne by bylo tez, gdyby zachowywalo sie to inaczej
> dla roznych typow indeksow.
Dziwne to jest np. to dlaczego PHP nie ma list, tylko protezę
w postaci specjalnego zachowania haszy. Chodzi w końcu o dość
podstawowy typ danych. Zmuszanie ludzi do używanie kulawej
pseudo-listy, ale za to powolnej, to jest dość typowy dla PHP
przypadek strzelania sobie w stopę.
>> to coś jest grubo nie tak. Kto konkretnie chwali te tablice i za
>> co, jeśli można wiedzieć?
>>
>> > a jesli chodzi o struktury danych...
>>
>> >http://www.php.net/manual/en/spl.datastructures.php
>>
>> To, że musisz sobie z czasem sztukować funkcjonalność
>> rozszerzeniami
>
> Jakie rozszwrzenie? Standard PHP Library - to sie tak nazywa.
Mhm. A ty oczywiście wiesz czym się różni _język_ od _standardowej
biblioteki_? I oczywiście ignorujesz przypadek skopanego int, które
trzeba obchodzić używając bcmath?
[...]
>> > Tak? Gdzie? Jak dla mnie to one dzialaja, jak pelnoprawne
>> > referencje.
>>
>> To są aliasy, nie referencje (w PHP poniżej 5).
>
> Czemu mamy rozmawiac o czyms, co juz nie jest nawet przez Zenda
> wspierane?!
Ważne jest, że jest stosowane. Sprawdź sobie ile jeszcze masz
instalacji PHP4.
> Moze pogadajmy o 'classic-style classes', albo pythonie
> 1.0? Taki doskonaly byl?
Możesz się zaperzać i wściekać, ale trudno ci będzie zmienić fakty.
Python, niezależnie od wersji, był zaprojektowanym przez fachowca
językiem ogólnego przeznaczenia, a nie powiązanym taśmą klejącą workiem
funkcyjek do obróbki formularzy HTML.
[...]
>> >> OOP jako afterthought, ledwo doprowadzone do używalności w PHP
>> >> 5.
>>
>> > Prosze Cie..
>>
>> O co?
>
> Nie rozumiem krytyki OOP - moze konkrety?
Czego konkretnie nie rozumiesz? Że OOP zostało zgodnie z pehapową
tradycją bezmyślnie doklejone taśmą do którejś kolejnej wersji?
Po prostu sprawdź kiedy i w jaki sposób się pojawiło. Według ciebie
w wersjach poniżej 5 to coś było używalne?
pakalk
> On 30 Paź, 08:24, pakalk <pak...@gmail.com> wrote:
>
> > On Oct 30, 12:10 am, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> > > Zapytaj kogoś, kto miał na studiach zajęcia ze struktur danych.
> > > Podpowiedź: wydajność.
>
> > Tylko, ze PHP nie ma wcale polaczonych list i hashy (map) w jednej
> > strukturze. Posiada tablice asocjacyjne.
>
> > > > Eeee... Tablice asocjacyjne z PHP sa powszechnie chwalone
>
> > > Przez kogo konkretnie?
>
> > Przez wiele osob.
>
> Dość enigmatyczne stwierdzenie.
Mam po nazwiskach jechac? :P
> Osobiście słyszałem 2 razy, by ktoś chwalił mix list/hash z php. Raz
> na grupie goldenline (nie pamiętam kto, ale argumenty nie były silne)
> i teraz Ty.
Ja pierwszy raz slysze, zeby ktos na nia narzekal, wiec 2-1 dla mnie.
>
> PHP jest sprytniejszy od przeciętnego programisty i sam ci
> przenumeruje twoje klucze na indexy, lub odwrotnie.
> Zbierz sobie w array dane cena produktu => ilość wystąpień np
> <?php
>
> $a = array(
> 1 => 13,
> 2 => 16,
> 2.29 => 17,
> 3 => 20,
> 3.14 => 23,
> );
>
> var_dump($a);
>
> + zalety słabego typowania:
>
> $a = array('bolek','lolek',0,'tola');
> var_dump(in_array('reksio', $a));
>
> i reksio ożywa
>
Sprawdze sobie. Moze i sa bugi, ale przypadki nieco wymyslone. W Javie
tez sie znajda kwiatki.
> czy inny przypadek literówki + słabe typowanie:
>
> <?php
>
> error_reporting(E_ALL);
>
> $ciag = "";
>
> $ciag[] .= 'Jezu';
> $ciag[] .= 'Chryste';
A co to za konstrukcja?
>
> var_dump($ciag);
>
> 'obsługa' dat jest cudowna, wystawmy sobie fakturkę
> <?php
> $t = '2003/02/30';
> var_dump(strtotime($t));
>
> radość księgowej - bezcenna
a co wychodzi? Moze format nie taki jak obslugiwany? Co sie wtedy
dziwic?
>
> i czym jest naprawdę static method
> <?php
> class B
> {
> public function rzyc()
> {
> $this->Atam();
> }
>
> }
>
> class A
> {
> public function test()
> {
> B::rzyc();
> }
>
> public function Atam()
> {
> var_dump('A TAM');
> }
>
> }
>
> $a = new A;
> $a->test();
W PHP5 takie wywolania generuja bledy. Wiem, ze to jest do dupy, ale
to spadek z PHP4.
Grzegorz Staniak
>> > Chyba nie zrozumiałeś :-/ Właśnie o tym piszę - PHP jest mocno
>> > ukierunkowany, przez co nie daje się w nim pisać aplikacji innych nie
>> > webowe,
>>
>> Nie do konca, bo skryptowo tez sobie radzi.
>
> Przykład: aplikacja www (php5) e-commerce zawierająca bazę ok 300k
> produktów, posiadających odpowiedniki np w 3 magazynach czyli + 900k
> wpisów,
> logika zamknięta w Propel (Peer), więc żeby logiki nie dublować
> skrypt analizujące ceny i stany magazynowe jest też w php5 uruchamiany
> z shell'a (cron).
>
> Robi to ok 5-6h na maszynie 4core, 8GB ramu, zużywając samemu ponad
> 512MB ramu, przy przetwarzaniu sekwencyjnym:
> * po 1 robi to wolno dlatego tyle czasu jedzie
> * po 2 cieknie wszędzie;
>
> po kompilacji php5.2.6 w trybie debug i wykonaniu F5 na prostym widoku
> symfony, debug zgłasza 20k-30k memory leaks detected.
>
> Reasumując w/g mnie skryptowo sobie nie radzi.
Bo nigdy nie było pisane jako język ogólnego zastosowania. Jeśli
cały runtime sprowadza się do pojedynczego wykonania na jednej
stronie, kto w ogóle ma motywację do szukania memory leaków?
Grzegorz Staniak
>> Wszystko w porzadku jak piszesz program dla siebie, ktory wrasta
>> sobie w twoj serwer i nigdy nie bedzie na niczym innym instalowany.
>> Nieco gorzej jest kiedy piszesz program, ktory chcesz dac ludziom
>> do sciagniecia i zainstalowania -- musisz dolaczyc instrukcje
>> jak skonfigurowac do niego interpreter. Kompletna klapa jesli
>> chcesz napisac program na zasadzie "rozpakuj i dziala" -- albo
>> przewidujesz i obslugujesz wszystkie mozliwe konfiguracje, albo
>> po prostu wybierasz jedna najpopularniejsza i olewasz wszystkich
>> innych uzytkownikow.
>
> Dranie z tych producentrow gier - na kazdym pudelku jest napisana
> konfiguracja minimalna do odpalenia gry. A co jakbym chcial na swoim
> 486 - nie zaziala... kurde!
>
> Serio: wymagania aplikacji chyba jakies sa - nie dziala w prozni.
To nie są wymagania aplikacji, tylko posrane założenia projektu
języka. Nie możesz być pewien jaki rozmiar ma int -- musisz używać
bcmath. Nie możesz być pewien, czy _ważne_ cechy języka nie są
włączone/wyłączone w danej instalacji -- napisz sobie tonę wrapperów
i kodu testującego i od ich wyników uzależniaj działanie aplikacji.
To jest po prostu sabotaż pracy programisty.
> Jak ktos nie umie sobie skonfigurowac, to nie umie.
Jak ktoś nie umie napisać języka programowania, to nie powinien
tego robić. Nie jest wcale dziwne, że pehap jest rekordzistą jeśli
chodzi o dziury bezpieczeństwa, skoro żeby ich uniknąć musisz
zignorować manuale i zamist pisać:
mysql_query("UPDATE users SET age='$age' WHERE id = '$id'");
zabezpieczać się np. tak:
if (get_magic_quotes_gpc()) {
$age = stripslashes($age);
}
mysql_query("UPDATE users SET age='".mysql_real_quote_string($age)."' WHERE id = '".mysql_real_quote_string($id)."'");
[...]
> Szczegolnie proste bedzie przejscie na pythona 3 z podstawowym
> printem ;)
Tak, to akurat będzie proste: 2to3 przerabia taki kod automatycznie
100/100.
> Ale ok - jest moze prosciej. Tylko nie chodzi mi o to gdzie jest
> prosciej, ale o to, ze argument jest nietrafiony.
Mało wiesz o PHP.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Wszystko w porzadku jak piszesz program dla siebie, ktory wrasta
> >> sobie w twoj serwer i nigdy nie bedzie na niczym innym instalowany.
> >> Nieco gorzej jest kiedy piszesz program, ktory chcesz dac ludziom
> >> do sciagniecia i zainstalowania -- musisz dolaczyc instrukcje
> >> jak skonfigurowac do niego interpreter. Kompletna klapa jesli
> >> chcesz napisac program na zasadzie "rozpakuj i dziala" -- albo
> >> przewidujesz i obslugujesz wszystkie mozliwe konfiguracje, albo
> >> po prostu wybierasz jedna najpopularniejsza i olewasz wszystkich
> >> innych uzytkownikow.
>
> > Dranie z tych producentrow gier - na kazdym pudelku jest napisana
> > konfiguracja minimalna do odpalenia gry. A co jakbym chcial na swoim
> > 486 - nie zaziala... kurde!
>
> > Serio: wymagania aplikacji chyba jakies sa - nie dziala w prozni.
>
> To nie są wymagania aplikacji, tylko posrane założenia projektu
To sa wymagania aplikacji. Konfigurowalne do tego w htaccess.
> języka. Nie możesz być pewien jaki rozmiar ma int -- musisz używać
> bcmath. Nie możesz być pewien, czy _ważne_ cechy języka nie są
> włączone/wyłączone w danej instalacji -- napisz sobie tonę wrapperów
> i kodu testującego i od ich wyników uzależniaj działanie aplikacji.
> To jest po prostu sabotaż pracy programisty.
>
> > Jak ktos nie umie sobie skonfigurowac, to nie umie.
>
> Jak ktoś nie umie napisać języka programowania, to nie powinien
> tego robić. Nie jest wcale dziwne, że pehap jest rekordzistą jeśli
> chodzi o dziury bezpieczeństwa, skoro żeby ich uniknąć musisz
> zignorować manuale i zamist pisać:
>
> mysql_query("UPDATE users SET age='$age' WHERE id = '$id'");
>
> zabezpieczać się np. tak:
>
> if (get_magic_quotes_gpc()) {
> $age = stripslashes($age);
> }
> mysql_query("UPDATE users SET age='".mysql_real_quote_string($age)."' WHERE id = '".mysql_real_quote_string($id)."'");
>
Widze, ze nie potrafisz uzywac PDO.
> [...]
>
> > Szczegolnie proste bedzie przejscie na pythona 3 z podstawowym
> > printem ;)
>
> Tak, to akurat będzie proste: 2to3 przerabia taki kod automatycznie
> 100/100.
>
> > Ale ok - jest moze prosciej. Tylko nie chodzi mi o to gdzie jest
> > prosciej, ale o to, ze argument jest nietrafiony.
>
> Mało wiesz o PHP.
>
Raczej sporo. Moze Ty malo wiesz i dlatego tak krzyczysz? Szczegolnie
o rzeczach, ktore byly aktualne w PHP3, 4?
pakalk
>
> Bo nigdy nie było pisane jako język ogólnego zastosowania. Jeśli
> cały runtime sprowadza się do pojedynczego wykonania na jednej
> stronie, kto w ogóle ma motywację do szukania memory leaków?
>
Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
Grzegorz Staniak
>> Bo nigdy nie było pisane jako język ogólnego zastosowania. Jeśli
>> cały runtime sprowadza się do pojedynczego wykonania na jednej
>> stronie, kto w ogóle ma motywację do szukania memory leaków?
>
> Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
Bo jego wady ujawniają się również w programowaniu WWW, jeśli
tylko wyjdziesz poza proste skrypciki.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Bo nigdy nie było pisane jako język ogólnego zastosowania. Jeśli
> >> cały runtime sprowadza się do pojedynczego wykonania na jednej
> >> stronie, kto w ogóle ma motywację do szukania memory leaków?
>
> > Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
>
> Bo jego wady ujawniają się również w programowaniu WWW, jeśli
> tylko wyjdziesz poza proste skrypciki.
>
Taka wikipedia rzeczywiscie nie wyrabia...
Grzegorz Staniak
>> >> Bo nigdy nie było pisane jako język ogólnego zastosowania.
>> >> Jeśli cały runtime sprowadza się do pojedynczego wykonania na
>> >> jednej stronie, kto w ogóle ma motywację do szukania memory
>> >> leaków?
>>
>> > Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
>>
>> Bo jego wady ujawniają się również w programowaniu WWW, jeśli
>> tylko wyjdziesz poza proste skrypciki.
>
> Taka wikipedia rzeczywiscie nie wyrabia...
Och, to teraz będzie licytacja typu "a X jednak używa PHP"? No to weź
sobie Facebook, największą chyba instalację PHP na świecie: kiedy mieli
ok. 2.5 mld odwiedzin dziennie, obsługiwali je używając 30 tys. serwerów
z PHP. Wychodzi mniej więcej 105-110 zapytań na godzinę na serwer.
Zdecydowanie jest się czym chwalić.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> >> Bo nigdy nie było pisane jako język ogólnego zastosowania.
> >> >> Jeśli cały runtime sprowadza się do pojedynczego wykonania na
> >> >> jednej stronie, kto w ogóle ma motywację do szukania memory
> >> >> leaków?
>
> >> > Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
>
> >> Bo jego wady ujawniają się również w programowaniu WWW, jeśli
> >> tylko wyjdziesz poza proste skrypciki.
>
> > Taka wikipedia rzeczywiscie nie wyrabia...
>
> Och, to teraz będzie licytacja typu "a X jednak używa PHP"? No to weź
> sobie Facebook, największą chyba instalację PHP na świecie: kiedy mieli
> ok. 2.5 mld odwiedzin dziennie, obsługiwali je używając 30 tys. serwerów
> z PHP. Wychodzi mniej więcej 105-110 zapytań na godzinę na serwer.
> Zdecydowanie jest się czym chwalić.
>
Nie, to nie jest licytacja. To jest dowod na nieprawdziwosc Twoich
argumentow. Nie potrafisz dyskutowac, uzywasz argumentow ad personam,
gdy wykazuje, ze mowisz nieprawde, to probujesz zmienic znaczenie
podanych faktow.
Grzegorz Staniak
>> >> >> Bo nigdy nie było pisane jako język ogólnego zastosowania.
>> >> >> Jeśli cały runtime sprowadza się do pojedynczego wykonania
>> >> >> na jednej stronie, kto w ogóle ma motywację do szukania
>> >> >> memory leaków?
>>
>> >> > Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
>>
>> >> Bo jego wady ujawniają się również w programowaniu WWW,
>> >> jeśli tylko wyjdziesz poza proste skrypciki.
>>
>> > Taka wikipedia rzeczywiscie nie wyrabia...
>>
>> Och, to teraz będzie licytacja typu "a X jednak używa PHP"? No
>> to weź sobie Facebook, największą chyba instalację PHP na
>> świecie: kiedy mieli ok. 2.5 mld odwiedzin dziennie, obsługiwali
>> je używając 30 tys. serwerów z PHP. Wychodzi mniej więcej
>> 105-110 zapytań na godzinę na serwer. Zdecydowanie jest się czym
>> chwalić.
>
> Nie, to nie jest licytacja. To jest dowod na nieprawdziwosc Twoich
> argumentow.
Na pewno bardzo chciałbyś, żeby to był dowód na cokolwiek, ale
niestety nie jest.
> Nie potrafisz dyskutowac, uzywasz argumentow ad personam
Wskazanie na twoją niewątpliwą ignorancję w temacie to nie jest
argument ad personam.
> gdy wykazuje, ze mowisz nieprawde
Jak dotąd ani razu nie wykazałeś, że mówię nieprawdę. Natomiast
sam bardzo starannie unikasz odnoszenia się do podawanych arghumentów.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
>
>
> >> >> >> Bo nigdy nie było pisane jako język ogólnego zastosowania.
> >> >> >> Jeśli cały runtime sprowadza się do pojedynczego wykonania
> >> >> >> na jednej stronie, kto w ogóle ma motywację do szukania
> >> >> >> memory leaków?
>
> >> >> > Wiec czemu jest krytykowany jako jezyk ogolnego zastosowania?
>
> >> >> Bo jego wady ujawniają się również w programowaniu WWW,
> >> >> jeśli tylko wyjdziesz poza proste skrypciki.
>
> >> > Taka wikipedia rzeczywiscie nie wyrabia...
>
> >> Och, to teraz będzie licytacja typu "a X jednak używa PHP"? No
> >> to weź sobie Facebook, największą chyba instalację PHP na
> >> świecie: kiedy mieli ok. 2.5 mld odwiedzin dziennie, obsługiwali
> >> je używając 30 tys. serwerów z PHP. Wychodzi mniej więcej
> >> 105-110 zapytań na godzinę na serwer. Zdecydowanie jest się czym
> >> chwalić.
>
> > Nie, to nie jest licytacja. To jest dowod na nieprawdziwosc Twoich
> > argumentow.
>
> Na pewno bardzo chciałbyś, żeby to był dowód na cokolwiek, ale
> niestety nie jest.
>
> > Nie potrafisz dyskutowac, uzywasz argumentow ad personam
>
> Wskazanie na twoją niewątpliwą ignorancję w temacie to nie jest
> argument ad personam.
Owszem jest, bo poza tym, ze "malo widziales" nic nie napisales, co by
to potwierdzalo. Twierdzisz bez zadnych konkretow, ze PHP nie daje
rady nawet z duzymi WWW - jak dla mnie wskazanie wikipedii, ktora na
PHP daje rade wystarczy, zeby ten Twoj argument okazal sie falszywy.
>
> > gdy wykazuje, ze mowisz nieprawde
>
> Jak dotąd ani razu nie wykazałeś, że mówię nieprawdę. Natomiast
> sam bardzo starannie unikasz odnoszenia się do podawanych arghumentów.
>
Wykazalem, ale Ty jak polityk - ignorujesz niewygodne fakty.
Grzegorz Staniak
>> Wskazanie na twoją niewątpliwą ignorancję w temacie to nie jest
>> argument ad personam.
>
> Owszem jest, bo poza tym, ze "malo widziales" nic nie napisales,
> co by to potwierdzalo.
To jest moja ocena, nie teza. Jeśli uważasz pehapowe tablice
za strukturę "powszechnie chwaloną", to najprawdopodobniej ani
nie znasz specjalnie innych języków, ani nawet z PHP nie pracowałeś
wystarczająco długo. Dziwne, że nie zauważyłeś, że udają również
listy.
> Twierdzisz bez zadnych konkretow, ze PHP nie daje rady nawet
> z duzymi WWW
Sorry, ale manipulujesz bardzo nieudolnie. Sprawdź co konkretnie
powiedziałem i bardzo proszę, nie przeinaczaj tylko dlatego, że
tak ci łatwiej odejść od tematu.
[...]
>> > gdy wykazuje, ze mowisz nieprawde
>>
>> Jak dotąd ani razu nie wykazałeś, że mówię nieprawdę.
>> Natomiast sam bardzo starannie unikasz odnoszenia się do
>> podawanych arghumentów.
>
> Wykazalem
Nie, nie wykazałeś. Wskaż konkretnie, co takiego niby było nieprawdą.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Wskazanie na twoją niewątpliwą ignorancję w temacie to nie jest
> >> argument ad personam.
>
> > Owszem jest, bo poza tym, ze "malo widziales" nic nie napisales,
> > co by to potwierdzalo.
>
> To jest moja ocena, nie teza. Jeśli uważasz pehapowe tablice
> za strukturę "powszechnie chwaloną", to najprawdopodobniej ani
> nie znasz specjalnie innych języków,
To tez nie jest ad personam, wcale.
> ani nawet z PHP nie pracowałeś
> wystarczająco długo. Dziwne, że nie zauważyłeś, że udają również
> listy.
To, ze probujesz ich uzywac jako list, to nie znaczy, ze one tego
chca. No ale.. Czep sie stringow, ze Ci udaja liczby.
>
> > Wykazalem
>
> Nie, nie wykazałeś. Wskaż konkretnie, co takiego niby było nieprawdą.
Juz pisalem kilka razy, nie bede sie powtarzal. Srednio rozgarniety
szympans by zrozumial, ze jesli mowi, ze PHP nie daje rady z wiekszymi
serwisami, a ja pokazuje przyklad wiekszego serwisu opartego na PHP,
to jest to wykazanie nieprawdy.
> Sorry, ale manipulujesz bardzo nieudolnie. Sprawdź co konkretnie
> powiedziałem i bardzo proszę, nie przeinaczaj tylko dlatego, że
> tak ci łatwiej odejść od tematu.
Kolejna polityczna zagrywka - zarzucic drugiej osobie to co sie samemu
robi. Jeszcze do tego tuz po tym, jak to zostalo wykryte.
----
Z politykami nie dyskutuje.
Grzegorz Staniak
>> >> Wskazanie na twoją niewątpliwą ignorancję w temacie to nie
>> >> jest argument ad personam.
>>
>> > Owszem jest, bo poza tym, ze "malo widziales" nic nie napisales,
>> > co by to potwierdzalo.
>>
>> To jest moja ocena, nie teza. Jeśli uważasz pehapowe tablice za
>> strukturę "powszechnie chwaloną", to najprawdopodobniej ani nie
>> znasz specjalnie innych języków,
>
> To tez nie jest ad personam, wcale.
Nie, nie jest.
>> ani nawet z PHP nie pracowałeś wystarczająco długo. Dziwne, że
>> nie zauważyłeś, że udają również listy.
>
> To, ze probujesz ich uzywac jako list, to nie znaczy, ze one tego
> chca.
Och, oczywiście. Składnię udającą listy mają zaiplementowaną
przypadkiem, przez przeoczenie. No i oczywiście mam wieeelki
wybór jeśli chcę użyć listy: albo array jako proteza, albo nic.
> No ale.. Czep sie stringow, ze Ci udaja liczby.
Gdyby jeszcze robiły to spójnie, to byłaby tylko głupia decyzja
autorów języka. Jeśli mimo to masz kwiatki typu:
(string) "false" == (int) 0 is True
to w dodatku implementacja jest skopana.
[...]
>> > Wykazalem
>>
>> Nie, nie wykazałeś. Wskaż konkretnie, co takiego niby było
>> nieprawdą.
>
> Juz pisalem kilka razy
Nie, nie pisałeś kilka razy. Usiłowałeś zbagatelizować lub pominąć
argumenty przeciwko, natomiast ani razu nie wykazałeś, że cokolwiek
z tego co pisałem jest nieprawdą.
> nie bede sie powtarzal. Srednio rozgarniety
> szympans by zrozumial, ze jesli mowi, ze PHP nie daje rady
> z wiekszymi serwisami
Powtarzanie kłamstwa kompromituje ciebie, nie mnie.
pakalk
oceniajac. No nie.... hahahaha
Marcin Nowak
> > Mało wiesz o PHP.
>
> Raczej sporo.
Sporo za mało. Polecam N.Wirth "Algorytmy i struktury danych",
nastepnie przemyslec to, o co sie klocilo.
No i cwiczyc, cwiczyc, cwiczyc... =)
Pozdrawiam,
Marcin
pakalk
A teraz...
http://php.net/manual/en/function.list.php
.. i się kłóćcie, że array do spółki z list symuluje krotki i ich
rozpakowywanie.
Pozniej natomiast mnie uswiadomcie w jaki sposob array() udaje Wam
liste, bo nie wiem nawet co to moze oznaczac. W dokumentacji jest jak
byk:
"An array in PHP is actually an ordered map. A map is a type that
associates values to keys."
a dalej
"it can be treated as an array, list (vector), hash table (an
implementation of a map), dictionary, collection, stack, queue, and
probably more."
co oznacza tyko tyle, ze opierajac sie na tablicach z PHP mozna
zrealizowac te struktury danych. Nie to, że array === list.
N/C
Grzegorz Staniak
>> >> Wszystko w porzadku jak piszesz program dla siebie, ktory wrasta
>> >> sobie w twoj serwer i nigdy nie bedzie na niczym innym instalowany.
>> >> Nieco gorzej jest kiedy piszesz program, ktory chcesz dac ludziom
>> >> do sciagniecia i zainstalowania -- musisz dolaczyc instrukcje
>> >> jak skonfigurowac do niego interpreter. Kompletna klapa jesli
>> >> chcesz napisac program na zasadzie "rozpakuj i dziala" -- albo
>> >> przewidujesz i obslugujesz wszystkie mozliwe konfiguracje, albo
>> >> po prostu wybierasz jedna najpopularniejsza i olewasz wszystkich
>> >> innych uzytkownikow.
>>
>> > Dranie z tych producentrow gier - na kazdym pudelku jest napisana
>> > konfiguracja minimalna do odpalenia gry. A co jakbym chcial na swoim
>> > 486 - nie zaziala... kurde!
>>
>> > Serio: wymagania aplikacji chyba jakies sa - nie dziala w prozni.
>>
>> To nie są wymagania aplikacji, tylko posrane założenia projektu
>
> To sa wymagania aplikacji.
Bzdura. To są ustawienia środowiska wykonania programu.
[...]
>> > Jak ktos nie umie sobie skonfigurowac, to nie umie.
>>
>> Jak ktoś nie umie napisać języka programowania, to nie powinien
>> tego robić. Nie jest wcale dziwne, że pehap jest rekordzistą jeśli
>> chodzi o dziury bezpieczeństwa, skoro żeby ich uniknąć musisz
>> zignorować manuale i zamist pisać:
>>
>> mysql_query("UPDATE users SET age='$age' WHERE id = '$id'");
>>
>> zabezpieczać się np. tak:
>>
>> if (get_magic_quotes_gpc()) {
>> $age = stripslashes($age);
>> }
>> mysql_query("UPDATE users SET age='".mysql_real_quote_string($age)."' WHERE id = '".mysql_real_quote_string($id)."'");
>
> Widze, ze nie potrafisz uzywac PDO.
Ale oczywiście odróżniasz język od bibliotek, prawda? Jak już
poprzednio zdołałeś udowodnić?
Grzegorz Staniak
> Pozniej natomiast mnie uswiadomcie w jaki sposob array() udaje Wam
> liste
Może inaczej: pokaż mi, jak użyć w PHP listy.
> bo nie wiem nawet co to moze oznaczac. W dokumentacji jest jak
> byk:
>
> "An array in PHP is actually an ordered map. A map is a type that
> associates values to keys."
Mhm. A składnia typu "$array = array('a', 'b', 'c');", z automatycznym
indeksowaniem integerami została do PHP dodana niechcący, kiedy kot
autora przespacerował się po klawiaturze.
> "it can be treated as an array, list (vector), hash table (an
> implementation of a map), dictionary, collection, stack, queue, and
> probably more."
>
> co oznacza tyko tyle, ze opierajac sie na tablicach z PHP mozna
> zrealizowac te struktury danych.
Peeewnie, że można. A jak się z tak realizowanej listy usunie jedną
pozycję, to nie można, ale _trzeba_ wywołać
$array = array_values($array);
żeby lista zachowała ciągłość indeksów. No, ale za to będzie powolna
jak hasz, więc hip hip hurra, niech żyją wymóżdżone struktury danych
w PHP!
Mariusz Kruk
>> >> > ..i wtedy wyjdzie, ze jak ktos z glowa do PHP podejdzie, to nie
>> >> > jest taki zly ten pehap.
>> >> Tu siďż˝ zgadzam.
>> >> �eby napisa� du�� i dobr� aplikacj� w PHP nie wystarczy tutorial,
>> >> var_dump i 1-2 lata klepania szablon�w w php (nie aplikacji).
>> > Ano nie wystarczy. Dlatego mysle, ze to programisci PHP sa zli,
>> > a nie jezyk.
>> J�zyk niezale�nie od wszystkiego innego te� jest zdrowo skopany.
>To znaczy? Co konkretnie?
Wystarczy, �e kto� wymy�li, �e pomi�dzy ma�ymi wersjami sobie zmieni
parametr wywo�ania funkcji np. z 1 na "True", co pi�knie rozk�ada
istniej�ce programy.
--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|
Marek Wywiał
Mówiąc 'duży' soft, co masz na mysli:
* ilość wpisów do prostych tabel
* ilośc ludzi znających wikipedia
czy ilość struktur danych, algorytmów wymaganych przez dziedzinę
problemu, ilość podsystemów integrujących się
z zewnętrznymi systemami.
Wikipedia oprócz jej znanych zalet dla ludzkości jest prostym skryptem
(nie aplikacją), który bez problemu może używać cache proxy
i wydalać ile chce.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> > Pozniej natomiast mnie uswiadomcie w jaki sposob array() udaje Wam
> > liste
>
> Może inaczej: pokaż mi, jak użyć w PHP listy.
Choćby i opierając się o tablice. Owszem, klucze nie będą się zgadzać
z kolejnością, tylko nie przypominam sobie, żeby to była własność
list. Natomiast kompletną bzdurą jest twierdzenie, że tablica to
lista, co wcześniej robiłeś.
>
> > bo nie wiem nawet co to moze oznaczac. W dokumentacji jest jak
> > byk:
>
> > "An array in PHP is actually an ordered map. A map is a type that
> > associates values to keys."
>
> Mhm. A składnia typu "$array = array('a', 'b', 'c');", z automatycznym
> indeksowaniem integerami została do PHP dodana niechcący, kiedy kot
> autora przespacerował się po klawiaturze.
Nie. Ale jak już pisałem, to skrót, gdy niepotrzebne są nam klucze.
Dziwne, że uproszczenie traktujesz jako wadę. Pewnie zrozumiałbyś,
gdyby zamiast kolejnych liczb z sekwencji były losowe hashe... Tak to
ciężko Ci pojąć, że to nie są indeksy.
>
> > "it can be treated as an array, list (vector), hash table (an
> > implementation of a map), dictionary, collection, stack, queue, and
> > probably more."
>
> > co oznacza tyko tyle, ze opierajac sie na tablicach z PHP mozna
> > zrealizowac te struktury danych.
>
> Peeewnie, że można. A jak się z tak realizowanej listy usunie jedną
> pozycję, to nie można, ale _trzeba_ wywołać
>
> $array = array_values($array);
Jak chcesz mieć ponumerowane elementy - to tak. I co? To znaczy, że
się nie da?
>
> żeby lista zachowała ciągłość indeksów. No, ale za to będzie powolna
> jak hasz,
Bo to jest tablica asocjacyjna, a nie lista.
> więc hip hip hurra, niech żyją wymóżdżone struktury danych
> w PHP!
Wymóżdżony to jesteś Ty. Idź sobie C ochrzań - tam też nie ma nic poza
tablicami właściwie. Trzeba sobie - olaboga - napisać.
Mariusz Kruk
>> rozmiaru nigdy nie mo�esz by� pewien (32-bit na systemach 32-bit,
>> 64-bit na 64-bitowych),
>No to mozesz byc pewien: 32 na 32, 64 na 64 :>
Ty tak powa�nie?
--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb
`b Kr...@epsilon.eu.org d'
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'
Grzegorz Staniak
>> > Pozniej natomiast mnie uswiadomcie w jaki sposob array() udaje
>> > Wam liste
>>
>> Może inaczej: pokaż mi, jak użyć w PHP listy.
>
> Choćby i opierając się o tablice. Owszem, klucze nie będą
> się zgadzać z kolejnością, tylko nie przypominam sobie, żeby
> to była własność list.
Bo niespecjalnie znasz inne, normalne języki. Wymień _jeden_
inny niż PHP, w którym po usunięciu elementu ze środka listy
zostaniesz z "dziurą" w indeksach.
> Natomiast kompletną bzdurą jest twierdzenie, że tablica to lista,
> co wcześniej robiłeś.
I znowu dość bezczelnie kłamiesz. Łatwo sprawdzić w wątku, co
mówiłem, nie rozumiem dlaczegi liczysz na to, że kłamstwo nie
zostanie zweryfikowane.
>> > bo nie wiem nawet co to moze oznaczac. W dokumentacji jest jak
>> > byk:
>>
>> > "An array in PHP is actually an ordered map. A map is a type that
>> > associates values to keys."
>>
>> Mhm. A składnia typu "$array = array('a', 'b', 'c');", z
>> automatycznym indeksowaniem integerami została do PHP dodana
>> niechcący, kiedy kot autora przespacerował się po klawiaturze.
>
> Nie. Ale jak już pisałem, to skrót, gdy niepotrzebne są nam
> klucze.
A dziwnym trafem klucze nie są nam potrzebne wtedy, kiedy chcemy
użyć listy, a nie hasza.
[...]
>> > "it can be treated as an array, list (vector), hash table (an
>> > implementation of a map), dictionary, collection, stack, queue,
>> > and probably more."
>>
>> > co oznacza tyko tyle, ze opierajac sie na tablicach z PHP mozna
>> > zrealizowac te struktury danych.
>>
>> Peeewnie, że można. A jak się z tak realizowanej listy usunie
>> jedną pozycję, to nie można, ale _trzeba_ wywołać
>>
>> $array = array_values($array);
>
> Jak chcesz mieć ponumerowane elementy - to tak. I co? To znaczy,
> że się nie da?
To znaczy, że język jest uperdliwy w użyciu, ponieważ wprowadza
wymóżdżone typy danych w stylu "hurra! hasz i lista w jednym!",
które nie są ani dobrą listą, ani dobrym haszem.
>> żeby lista zachowała ciągłość indeksów. No, ale za to
>> będzie powolna jak hasz,
>
> Bo to jest tablica asocjacyjna, a nie lista.
No co ty? A podobno można nią sobie zaimplementować i listę.
Jak to zrobić, żeby uniknąć upierdliwości typu reindeksowanie,
albo mieć wydajność listy?
> Wymóżdżony to jesteś Ty. Idź sobie C ochrzań - tam też nie ma
> nic poza tablicami właściwie. Trzeba sobie - olaboga - napisać.
Tak tak, oczywiście u nich biją murzynów.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
> >> > Pozniej natomiast mnie uswiadomcie w jaki sposob array() udaje
> >> > Wam liste
>
> >> Może inaczej: pokaż mi, jak użyć w PHP listy.
>
> > Choćby i opierając się o tablice. Owszem, klucze nie będą
> > się zgadzać z kolejnością, tylko nie przypominam sobie, żeby
> > to była własność list.
>
> Bo niespecjalnie znasz inne, normalne języki. Wymień _jeden_
> inny niż PHP, w którym po usunięciu elementu ze środka listy
> zostaniesz z "dziurą" w indeksach.
Struktury danych nie są zależne od języka. To raz. Dwa - listy nie
posiadają indeksów jak tablice.
>
> > Natomiast kompletną bzdurą jest twierdzenie, że tablica to lista,
> > co wcześniej robiłeś.
>
> I znowu dość bezczelnie kłamiesz. Łatwo sprawdzić w wątku, co
> mówiłem, nie rozumiem dlaczegi liczysz na to, że kłamstwo nie
> zostanie zweryfikowane.
No właśnie łatwo. To sobie sprawdź czy nie pisałeś, że tablice udają
Ci listy.
>
> >> > bo nie wiem nawet co to moze oznaczac. W dokumentacji jest jak
> >> > byk:
>
> >> > "An array in PHP is actually an ordered map. A map is a type that
> >> > associates values to keys."
>
> >> Mhm. A składnia typu "$array = array('a', 'b', 'c');", z
> >> automatycznym indeksowaniem integerami została do PHP dodana
> >> niechcący, kiedy kot autora przespacerował się po klawiaturze.
>
> > Nie. Ale jak już pisałem, to skrót, gdy niepotrzebne są nam
> > klucze.
>
> A dziwnym trafem klucze nie są nam potrzebne wtedy, kiedy chcemy
> użyć listy, a nie hasza.
To co Ty chcesz z tym zrobić to nie jest wiadome dla PHP-a. Ja np.
chciałbym to użyć jako zbiór powtarzających się elementów. I co?
>
> >> > "it can be treated as an array, list (vector), hash table (an
> >> > implementation of a map), dictionary, collection, stack, queue,
> >> > and probably more."
>
> >> > co oznacza tyko tyle, ze opierajac sie na tablicach z PHP mozna
> >> > zrealizowac te struktury danych.
>
> >> Peeewnie, że można. A jak się z tak realizowanej listy usunie
> >> jedną pozycję, to nie można, ale _trzeba_ wywołać
>
> >> $array = array_values($array);
>
> > Jak chcesz mieć ponumerowane elementy - to tak. I co? To znaczy,
> > że się nie da?
>
> To znaczy, że język jest uperdliwy w użyciu, ponieważ wprowadza
> wymóżdżone typy danych w stylu "hurra! hasz i lista w jednym!",
> które nie są ani dobrą listą, ani dobrym haszem.
No i znów oczywiście nie twierdzisz, że tablica ma byc listą, bo Ty
tak sobie wymyśliłeś.
>
> >> żeby lista zachowała ciągłość indeksów. No, ale za to
> >> będzie powolna jak hasz,
>
> > Bo to jest tablica asocjacyjna, a nie lista.
>
> No co ty? A podobno można nią sobie zaimplementować i listę.
> Jak to zrobić, żeby uniknąć upierdliwości typu reindeksowanie,
> albo mieć wydajność listy?
Zrób sobie klasę. Takie kretyńskie pytania zadajesz. A jak za pomocą
struktur i wskaźników w C zrobić listę? A sorry... do C nie doszedłeś.
Grzegorz Staniak
>> >> > Pozniej natomiast mnie uswiadomcie w jaki sposob array() udaje
>> >> > Wam liste
>>
>> >> Może inaczej: pokaż mi, jak użyć w PHP listy.
>>
>> > Choćby i opierając się o tablice. Owszem, klucze nie będą
>> > się zgadzać z kolejnością, tylko nie przypominam sobie, żeby
>> > to była własność list.
>>
>> Bo niespecjalnie znasz inne, normalne języki. Wymień _jeden_
>> inny niż PHP, w którym po usunięciu elementu ze środka listy
>> zostaniesz z "dziurą" w indeksach.
>
> Struktury danych nie są zależne od języka.
Cool. A teraz wymień język inny niż PHP w których masz listy
jako typ danych, a po usunięciu elementu zostaje ci dziura
w indeksach.
[...]
>> > Natomiast kompletną bzdurą jest twierdzenie, że tablica to
>> > lista, co wcześniej robiłeś.
>>
>> I znowu dość bezczelnie kłamiesz. Łatwo sprawdzić w wątku, co
>> mówiłem, nie rozumiem dlaczegi liczysz na to, że kłamstwo nie
>> zostanie zweryfikowane.
>
> No właśnie łatwo. To sobie sprawdź czy nie pisałeś, że
> tablice udają Ci listy.
Zacytuj.
[...]
>> >> Mhm. A składnia typu "$array = array('a', 'b', 'c');",
>> >> z automatycznym indeksowaniem integerami została do PHP
>> >> dodana niechcący, kiedy kot autora przespacerował się po
>> >> klawiaturze.
>>
>> > Nie. Ale jak już pisałem, to skrót, gdy niepotrzebne są nam
>> > klucze.
>>
>> A dziwnym trafem klucze nie są nam potrzebne wtedy, kiedy chcemy
>> użyć listy, a nie hasza.
>
> To co Ty chcesz z tym zrobić to nie jest wiadome dla PHP-a.
Masz sto procent racji: potrzeby programistów to jest coś, co
od początku było dla autorów PHP niewiadomą.
[...]
>> >> Peeewnie, że można. A jak się z tak realizowanej listy usunie
>> >> jedną pozycję, to nie można, ale _trzeba_ wywołać
>>
>> >> $array = array_values($array);
>>
>> > Jak chcesz mieć ponumerowane elementy - to tak. I co? To znaczy,
>> > że się nie da?
>>
>> To znaczy, że język jest uperdliwy w użyciu, ponieważ wprowadza
>> wymóżdżone typy danych w stylu "hurra! hasz i lista w jednym!",
>> które nie są ani dobrą listą, ani dobrym haszem.
>
> No i znów oczywiście nie twierdzisz, że tablica ma byc listą
Kochany ciężko sklerotyczny kolego, to ty sam przed chwilką
opowiadałeś jak to można sobie przy pomocy tablic zaimplementować
listę. Pokaż mi wobec tego jak: tak żebym nie musiał reindeksować
i miał wydajność porównywalną chociaż z listami w innych językach.
[...]
>> >> żeby lista zachowała ciągłość indeksów. No, ale za to
>> >> będzie powolna jak hasz,
>>
>> > Bo to jest tablica asocjacyjna, a nie lista.
>>
>> No co ty? A podobno można nią sobie zaimplementować i listę.
>> Jak to zrobić, żeby uniknąć upierdliwości typu reindeksowanie,
>> albo mieć wydajność listy?
>
> Zrób sobie klasę.
Innymi słowy: trać czas, bo autorowi języka nie chciało się
pomyśleć przy implementacji typów danych.
> Takie kretyńskie pytania zadajesz. A jak za pomocą struktur
> i wskaźników w C zrobić listę? A sorry... do C nie doszedłeś.
Tak tak, u nich oczywiście biją murzynów.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
>
> Cool. A teraz wymień język inny niż PHP w których masz listy
> jako typ danych, a po usunięciu elementu zostaje ci dziura
> w indeksach.
>
Po co?
Zreszta, to zalezy od implementacji.
>
> > To co Ty chcesz z tym zrobić to nie jest wiadome dla PHP-a.
>
> Masz sto procent racji: potrzeby programistów to jest coś, co
> od początku było dla autorów PHP niewiadomą.
>
No na pewno nie przewidzieli, ze ktos sie bedzie burzyl, ze klucze nie
sa przenumerowane, bo moze to zrobic samemu - w druga strone byloby
ciezej.
>
> > No i znów oczywiście nie twierdzisz, że tablica ma byc listą
>
> Kochany ciężko sklerotyczny kolego, to ty sam przed chwilką
> opowiadałeś jak to można sobie przy pomocy tablic zaimplementować
To, ze mozna jej uzyc do implementacji listy, nie oznacza, ze ona jest
lista.
> listę. Pokaż mi wobec tego jak: tak żebym nie musiał reindeksować
To nie sa indeksy, tylko klucze
> i miał wydajność porównywalną chociaż z listami w innych językach.
>
Narzekales na funkcjonalnosc i tego dotyczyla moja krytyka.
>
> > Zrób sobie klasę.
>
> Innymi słowy: trać czas, bo autorowi języka nie chciało się
> pomyśleć przy implementacji typów danych.
No to wykorzystaj zrobiona przez kogos.
>
> > Takie kretyńskie pytania zadajesz. A jak za pomocą struktur
> > i wskaźników w C zrobić listę? A sorry... do C nie doszedłeś.
>
> Tak tak, u nich oczywiście biją murzynów.
>
Nie lubisz murzynow, czy co? Nie rozumiesz, ze nie wszystko musi byc
wbudowane w jezyk i nie ma to zwiazku z tym, czy w PHP da sie (bo sie
da) stworzyc i uzywac listy ponumerowanej, nieponumerowanej, jedno,
dwu czy szenasto kierunkowej?
Twoje zarzuty dotycza tego, ze przez (ile? 9 lat?) nie zauwazyles, ze
tablica to nie jest lista i nie posiada takiej funkcjonalnosci jak
lista. Wobec tego nie powinna byc stosowana jako lista. Co wiecej:
autorzy pisza, ze to nie lista tylko uporzadkowana mapa - ale nie.. Ty
wiesz lepiej, ze oni chcieli zrobic zjechana (tez wg Ciebie, bo nie ma
indeksow, ktorych listy nie maja!) liste. No ale przeciez Ty chcesz,
zeby sie zachowywala inaczej, wiec to PHP jest zly. Natomiast
napisanie jednej linii kodu (array_values()) jest dla Ciebie takim
wyczynem, ze kjm. Co by bylo, gdyby indeksy byly zmieniane, tak jak
chcesz? (Tzn. klucze byly traktowane jak indeksy). 1. Jak ktos sobie
uzna, ze chce miec dziury (bo mu potrzebne klucze numeryczne a nie
indeksy), to nie bedzie mial. 2. Obsluga array() bedzie niespojna -
liczby sie beda zmieniac (nie wiadomo czemu), stringi nie...
Teraz zadanie domowe dla Ciebie i innych wielkich teoretykow struktur
danych z wieloletnim doswiadczeniem. Poindeksujcie sobie liste
dwukierunkowa. A potem cykliczna.
Ups... nie slyszeliscie? No moze, bo to co w Pythonie nazywa sie
lista, to tablica dynamiczna... jakbym byl zlosliwy, tobym powiedzial,
ze udajaca liste (i stos przy okazji). Ale nie powiem, bo wiem ze
wlasciwosci struktur danych potrafia sie zazębiac, a w powszechnych
implementacjach jest wiecej mozliwosci niz w tym, co sprawia, ze stos
jest stosem, a kolejka kolejka.
Grzegorz Staniak
>> > Struktury danych nie są zależne od języka.
>>
>> Cool. A teraz wymień język inny niż PHP w których masz listy
>> jako typ danych, a po usunięciu elementu zostaje ci dziura
>> w indeksach.
>
> Po co?
Tak dla porównania i ustalenia uwagi: żebyś miał kontekst
dla określenia tych typów danych takimi przymiotnikami jak
np. "wymóżdżone".
> Zreszta, to zalezy od implementacji.
Fajnie. Podaj przykład implementacji takiej jak w PHP.
>> > To co Ty chcesz z tym zrobić to nie jest wiadome dla PHP-a.
>>
>> Masz sto procent racji: potrzeby programistów to jest coś, co
>> od początku było dla autorów PHP niewiadomą.
>
> No na pewno nie przewidzieli, ze ktos sie bedzie burzyl, ze klucze nie
> sa przenumerowane, bo moze to zrobic samemu - w druga strone byloby
> ciezej.
Autorom byłoby ciężej zaimplementować porządne listy i normalne
hasze? Być może. Jednak autorom innych języków jakoś się to udawało.
>> > No i znów oczywiście nie twierdzisz, że tablica ma byc listą
>>
>> Kochany ciężko sklerotyczny kolego, to ty sam przed chwilką
>> opowiadałeś jak to można sobie przy pomocy tablic zaimplementować
>
> To, ze mozna jej uzyc do implementacji listy, nie oznacza, ze ona jest
> lista.
Nie jest listą, nie jest haszem, jest wymóżdżonym wynalazkiem który
usiłuje udawać jedno i drugie naraz.
>> listę. Pokaż mi wobec tego jak: tak żebym nie musiał reindeksować
>
> To nie sa indeksy, tylko klucze
>
>> i miał wydajność porównywalną chociaż z listami w innych językach.
>
> Narzekales na funkcjonalnosc i tego dotyczyla moja krytyka.
Dla dość swobodnie zdefiniowanego pojęcia "krytyki". Nie podejmujesz
rozmowy, tylko schodzisz na jakieś "no i co z tego? znaczy nie da
się?" albo w ogóle wyjeżdżasz z jakimś C, gdzie jest gorzej.
>> > Zrób sobie klasę.
>>
>> Innymi słowy: trać czas, bo autorowi języka nie chciało się
>> pomyśleć przy implementacji typów danych.
>
> No to wykorzystaj zrobiona przez kogos.
Słuchaj, jeśli będę postawiony w sytuacji kiedy muszę szukać obejść,
to albo znajdę obejścia, albo najpewniej użyję innego języka. Nie bawimy
się w porady dla użytkowników, tylko rozmawiamy o samym języku. Jeśli
na każdym kroku zmusza do podobnych obejść, to ktoś jednak nie pomyślał
przy jego projektowaniu.
>> > Takie kretyńskie pytania zadajesz. A jak za pomocą struktur
>> > i wskaźników w C zrobić listę? A sorry... do C nie doszedłeś.
>>
>> Tak tak, u nich oczywiście biją murzynów.
>
> Nie lubisz murzynow, czy co? Nie rozumiesz, ze nie wszystko musi byc
> wbudowane w jezyk
... co autorom PHP nie przeszkodziło we wbudowaniu w język tysięcy
funkcji w jednej przestrzeni nazw, prawda?
> i nie ma to zwiazku z tym, czy w PHP da sie (bo sie
> da) stworzyc i uzywac listy ponumerowanej, nieponumerowanej, jedno,
> dwu czy szenasto kierunkowej?
Stary, jak się człowiek uprze, to napisze webowy sklepik w
asemblerze.
> Twoje zarzuty dotycza tego, ze przez (ile? 9 lat?) nie zauwazyles, ze
> tablica to nie jest lista i nie posiada takiej funkcjonalnosci jak
> lista. Wobec tego nie powinna byc stosowana jako lista.
Cool. A jeśli potrzebuję listy, to co makm do wyboru? Array albo
array, ewentualnie array? To jak podziękuję za język wykastrowany
z podstawowej funkcjonalności i użyję czegoś, co mi nie rzuca kłód
pod nogi.
pakalk
> On 30.10.2009, pakalk <pak...@gmail.com> wroted:
>
>
> >> Masz sto procent racji: potrzeby programistów to jest coś, co
> >> od początku było dla autorów PHP niewiadomą.
>
> > No na pewno nie przewidzieli, ze ktos sie bedzie burzyl, ze klucze nie
> > sa przenumerowane, bo moze to zrobic samemu - w druga strone byloby
> > ciezej.
>
> Autorom byłoby ciężej zaimplementować porządne listy i normalne
> hasze? Być może. Jednak autorom innych języków jakoś się to udawało.
Nie wiem co masz do PHP-owych haszy. List nie zaimplementowali, bo
nie. I co? Czy ktos sie rzuca, ze w pythonie nie ma na przyklad
podstawowej petli do..while?
>
> >> > No i znów oczywiście nie twierdzisz, że tablica ma byc listą
>
> >> Kochany ciężko sklerotyczny kolego, to ty sam przed chwilką
> >> opowiadałeś jak to można sobie przy pomocy tablic zaimplementować
>
> > To, ze mozna jej uzyc do implementacji listy, nie oznacza, ze ona jest
> > lista.
>
> Nie jest listą, nie jest haszem, jest wymóżdżonym wynalazkiem który
> usiłuje udawać jedno i drugie naraz.
Z Toba nie ma sensu rozmawiac. Jeszcze raz Ci napisze
"An array in PHP is actually an ordered map. A map is a type that
associates values to keys."
>
> >> listę. Pokaż mi wobec tego jak: tak żebym nie musiał reindeksować
>
> > To nie sa indeksy, tylko klucze
>
> >> i miał wydajność porównywalną chociaż z listami w innych językach.
>
> > Narzekales na funkcjonalnosc i tego dotyczyla moja krytyka.
>
> Dla dość swobodnie zdefiniowanego pojęcia "krytyki". Nie podejmujesz
> rozmowy, tylko schodzisz na jakieś "no i co z tego?
Jak opowiadasz jakies banialuki, to sie pytam co z tego. Co innego mam
odpisac?
> znaczy nie da
> się?" albo w ogóle wyjeżdżasz z jakimś C, gdzie jest gorzej.
"Jakimś C" - po prostu pokazuje Twoj poziom. Jesli nie ma czegos w
jezyku, to nie potrafisz sobie poradzic.
To "jakies C" natomiast jest silnie z cpythonem powiazane.
>
> >> > Zrób sobie klasę.
>
> >> Innymi słowy: trać czas, bo autorowi języka nie chciało się
> >> pomyśleć przy implementacji typów danych.
>
> > No to wykorzystaj zrobiona przez kogos.
>
> Słuchaj, jeśli będę postawiony w sytuacji kiedy muszę szukać obejść,
> to albo znajdę obejścia, albo najpewniej użyję innego języka.
Oczywiscie, bo latwiej wszystko przepisac na inny jezyk niz napisac
$array = array_values( $array );
> Nie bawimy
> się w porady dla użytkowników, tylko rozmawiamy o samym języku. Jeśli
> na każdym kroku zmusza do podobnych obejść, to ktoś jednak nie pomyślał
> przy jego projektowaniu.
Dla normalnego programisty to normalne, ze stosuje biblioteki, jesli
czegos nie da sie zrobic w samym jezyku.
>
> ... co autorom PHP nie przeszkodziło we wbudowaniu w język tysięcy
> funkcji w jednej przestrzeni nazw, prawda?
Bo nie bylo nic takiego jak przestrzenie, ale tego nie rozumiesz. No
przeciez, jak nie ma przestrzeni to i tak trzeba umieszczac funkcje w
roznych przestrzeniach.
> > Twoje zarzuty dotycza tego, ze przez (ile? 9 lat?) nie zauwazyles, ze
> > tablica to nie jest lista i nie posiada takiej funkcjonalnosci jak
> > lista. Wobec tego nie powinna byc stosowana jako lista.
>
> Cool. A jeśli potrzebuję listy, to co makm do wyboru? Array albo
> array, ewentualnie array? To jak podziękuję za język wykastrowany
> z podstawowej funkcjonalności i użyję czegoś, co mi nie rzuca kłód
> pod nogi.
Jakby to powiedzial dr House: jestes idiota. Dobranoc.
Grzegorz Staniak
>> >> > To co Ty chcesz z tym zrobić to nie jest wiadome dla PHP-a.
>>
>> >> Masz sto procent racji: potrzeby programistów to jest coś, co
>> >> od początku było dla autorów PHP niewiadomą.
>>
>> > No na pewno nie przewidzieli, ze ktos sie bedzie burzyl, ze
>> > klucze nie sa przenumerowane, bo moze to zrobic samemu - w druga
>> > strone byloby ciezej.
>>
>> Autorom byłoby ciężej zaimplementować porządne listy i
>> normalne hasze? Być może. Jednak autorom innych języków jakoś
>> się to udawało.
>
> Nie wiem co masz do PHP-owych haszy. List nie zaimplementowali, bo
> nie. I co? Czy ktos sie rzuca, ze w pythonie nie ma na przyklad
> podstawowej petli do..while?
A ty po prostu nie potrafisz argumentować inaczej niż przez "a u was
biją murzynów"? Twierdziłeś, że "to programiści PHP są źli, a nie sam
język". Otóż sam język ma też sporą liczbę cech, które mają duży
udział w tworzeniu "getta PHP".
[...]
> Z Toba nie ma sensu rozmawiac. Jeszcze raz Ci napisze
>
> "An array in PHP is actually an ordered map. A map is a type that
> associates values to keys."
Powienieneś też od razu wkleić ten kawałek o tym jak to można sobie
nimi zaimplementować listę. Upierdliwą w użyciu i mało wydajną, ale
jak rozumiem to dla ciebie nieważne detale. I wyjaśnij jeszcze, skąd
się wzięła składnia udająca listy, skoro to takie oczywiste, że list
nie ma, a array jest typem mapującym.
[...]
>> znaczy nie da się?" albo w ogóle wyjeżdżasz z jakimś C, gdzie
>> jest gorzej.
>
> "Jakimś C" - po prostu pokazuje Twoj poziom. Jesli nie ma czegos w
> jezyku, to nie potrafisz sobie poradzic.
... powiedział gostek, który się skarżył na adpersony. Porównuj
jabłka z jabłkami, matołku. Wyjeżdżanie z C w rozmowie o języku
wysokiego poziomu takim jak PHP to zwykła demagogia. Może od
razu zejdź do asemblera i opowiedz jakich tam brakuje typów
danych.
[...]
>> Słuchaj, jeśli będę postawiony w sytuacji kiedy muszę szukać
>> obejść, to albo znajdę obejścia, albo najpewniej użyję innego
>> języka.
>
> Oczywiscie, bo latwiej wszystko przepisac na inny jezyk niz napisac
>
> $array = array_values( $array );
Najłatwiej jest od początku używać sensownych narzędzi, nie będzie
potrzeby przepisywania czegkolwiek.
>> Nie bawimy się w porady dla użytkowników, tylko rozmawiamy
>> o samym języku. Jeśli na każdym kroku zmusza do podobnych
>> obejść, to ktoś jednak nie pomyślał przy jego projektowaniu.
>
> Dla normalnego programisty to normalne, ze stosuje biblioteki
A my nie mówimy o tym, co jest normalne, tylko o "samym języku".
[...]
>> ... co autorom PHP nie przeszkodziło we wbudowaniu w język
>> tysięcy funkcji w jednej przestrzeni nazw, prawda?
>
> Bo nie bylo nic takiego jak przestrzenie
To nie mój problem i nie moja wina. Wielki wór tysięcy chaotycznie
nazwanych i zachowujących się funkcji jest jedną z głównych
przyczyn dla których "sam język" też jest "zły", a nie tylko
programiści. Twój zapał świeżo nawróconego fanboja tego niestety
nie zmieni.
Jaroslaw Zabiello
Od siebie dodam jeszcze to http://gist.github.com/127274
Daniel Mróz
> Owszem jest, bo poza tym, ze "malo widziales" nic nie napisales, co by
> to potwierdzalo. Twierdzisz bez zadnych konkretow, ze PHP nie daje
> rady nawet z duzymi WWW - jak dla mnie wskazanie wikipedii, ktora na
> PHP daje rade wystarczy, zeby ten Twoj argument okazal sie falszywy.
dynamiczną. Interpreter ma tam niewiele roboty, a i pewnie samych odwołań
do niego jest mało, bo content serwują revproxy (IIRC). To nie jest dobry
przykład dużej aplikacji. Facebook jest dobrym przykładem - dynamiczny,
działający niestety powolnie, często padający (najczęsciej wtedy, gdy Zynga
wrzuci jakiś loot week na Mafia Wars i kupa ludu sztormuje serwery).
Przydałby się jakiś kontrprzykład podobnego kalibru.
Pozdrawiam
Beorn
--
Daniel 'Beorn' Mróz <be...@alpha.pl> http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*]
[ r++ y+ ]
Grzegorz Staniak
>> Owszem jest, bo poza tym, ze "malo widziales" nic nie napisales, co
>> by to potwierdzalo. Twierdzisz bez zadnych konkretow, ze PHP nie
>> daje rady nawet z duzymi WWW - jak dla mnie wskazanie wikipedii,
>> ktora na PHP daje rade wystarczy, zeby ten Twoj argument okazal sie
>> falszywy.
>
> Nie powinienem, ale się delikatnie wtrącę. Wikipedia jest
> aplikacją mało dynamiczną. Interpreter ma tam niewiele roboty, a
> i pewnie samych odwołań do niego jest mało, bo content serwują
> revproxy (IIRC). To nie jest dobry przykład dużej aplikacji.
> Facebook jest dobrym przykładem - dynamiczny, działający niestety
> powolnie, często padający (najczęsciej wtedy, gdy Zynga wrzuci
> jakiś loot week na Mafia Wars i kupa ludu sztormuje serwery).
> Przydałby się jakiś kontrprzykład podobnego kalibru.
Google i Python?
Daniel Mróz
>> Przydałby się jakiś kontrprzykład podobnego kalibru.
> Google i Python?
w takich zastosowaniach. Chodzi mi o duży, dynamiczny portal w PHP,
inny niż nieco bardziej rozbudowany silnik szablonów jakim jest Wikipedia.
Kontynuujcie.
Piotr Keplicz
> Nie, nie. Kontrprzykład w PHP. Pythona nie trzeba zbytnio przedstawiać
> w takich zastosowaniach. Chodzi mi o duży, dynamiczny portal w PHP,
> inny niż nieco bardziej rozbudowany silnik szablonów jakim jest Wikipedia.
> Kontynuujcie.
Yahoo. Przynajmniej kilka lat temu, nie wiem jak obecnie.
.pk.
Marek Wywiał
w yahoo delicious, ale tylko wyrzut danych na ekran (prawdopodobnie
symfony)
natomiast w środku jest erlang:
* http://blog.socklabs.com/cufp2008.pdf
Jaroslaw Zabiello
>> Mechanizm wyjątków nie czyni jezyka wyjątkowym
>>
>> wyjątkowym może nie, ale bezpieczniejszym i łatwiejszym w użyciu.
>> Wole dostać wyjątek, że nie zdefiniowałem zmiennej niż przesłać tą
>> niezdefiniowaną zmienną
>> do miliona rekordów w bazie czyszcząc wpisy i dowiedzieć się o tym po
>> fakcie przeglądając bazę
>> lub logi z php.
>
> set_error_handler()
> set_exception_handler()
Niestety, ale twój adwersasz ma rację. W PHP błędy wyłapuje się po faktach
z logów.
Zarówno set_error_handler() jak i set_exception_handler() niewiele mogą.
Wystarczy jeden, drobny błąd w zwracanych danych aby rozkraczyć każdą,
choćby nie wiem jak zabezpieczoną, aplikację PHP (Jest tak dlatego, że
idioci, co tworzyli ten język zadecydowali że błędy fatalne nie powinno
się ograniczać tylko do błędu w parsowaniu składni). Jak nie wierzysz, to
spróbuj programowo przechwycić poniższą sytuację. Nie wyłapiesz tego ani
try-catchem ani niczym innym.
function jakis_kod() { return null; }
$obj = jakis_kod();
$obj->jakas_metoda(); # hehe, php leży i kwiczy
To jest po prostu kompletna kompromitacja dla tego języka. Pehap wywali
się z kretyńskim błędem "Fatal error: Call to a member function
jakas_metoda() on a non-object". Nic nie jest w stanie tego powstrzymać.
Już upierdliwy javowy NullPointerException jest lepszy, bo jest wyjątkiem,
a wyjątki można wychwycić. Natomiast o tym że miał miejsce fatal error
można dowiedzieć się tylko z logów. Lub z pustego ekranu, jak ma się tą
wątpliwą przyjemność natrafić na coś takiego przy przeladowywaniu strony.
Innymi słowy, PHP nie jest w stanie dostarczyć więc szczelnego,
zautomatyzowanego systemu wyłapywania błędów tak, jak to jest Django, czy
web2py. Jedyne co można zrobić to mozolnie przetwarzać i analizować logi
aby wyłuskiwać z nich takie błędy które wcześniej się pojawiły.
--
JZ http://blog.zabiello.com
pakalk
> Dnia 29-10-2009 o 10:05:29 pakalk <pak...@gmail.com> napisał(a):
>
> >> Mechanizm wyjątków nie czyni jezyka wyjątkowym
>
> >> wyjątkowym może nie, ale bezpieczniejszym i łatwiejszym w użyciu.
> >> Wole dostać wyjątek, że nie zdefiniowałem zmiennej niż przesłać tą
> >> niezdefiniowaną zmienną
> >> do miliona rekordów w bazie czyszcząc wpisy i dowiedzieć się o tym po
> >> fakcie przeglądając bazę
> >> lub logi z php.
>
> > set_error_handler()
> > set_exception_handler()
>
> Niestety, ale twój adwersasz ma rację. W PHP błędy wyłapuje się po faktach
> z logów.
Da sie czasem cos wylapac w locie ;)
>
> Zarówno set_error_handler() jak i set_exception_handler() niewiele mogą.
> Wystarczy jeden, drobny błąd w zwracanych danych aby rozkraczyć każdą,
> choćby nie wiem jak zabezpieczoną, aplikację PHP (Jest tak dlatego, że
> idioci, co tworzyli ten język zadecydowali że błędy fatalne nie powinno
> się ograniczać tylko do błędu w parsowaniu składni). Jak nie wierzysz, to
> spróbuj programowo przechwycić poniższą sytuację. Nie wyłapiesz tego ani
> try-catchem ani niczym innym.
>
> function jakis_kod() { return null; }
> $obj = jakis_kod();
> $obj->jakas_metoda(); # hehe, php leży i kwiczy
Tak, racja. Tutaj jest do dupy. Da sie to wylapac, ale nie da sie
obsluzyc.
Ewentualnie...
function jakis_kod()
{
return null;
}
$obj = jakis_kod();
if ( $obj !== null )
{
$obj->jakas_metoda();
}
;)
Jaroslaw Zabiello
>> function jakis_kod() { return null; }
>> $obj = jakis_kod();
>> $obj->jakas_metoda(); # hehe, php leży i kwiczy
>
> Tak, racja. Tutaj jest do dupy. Da sie to wylapac, ale nie da sie
> obsluzyc.
>
> Ewentualnie...
>
> function jakis_kod()
> {
> return null;
> }
>
> $obj = jakis_kod();
>
> if ( $obj !== null )
> {
> $obj->jakas_metoda();
> }
> ;
Prawda, jakie to wspaniałe, że w PHP trzeba sprawdzać wartość każdej
zmiennej przed jej użyciem aby uniknąć kompletnego upadku całej aplikacji?
To, że to wygląda jak kupa to jedno. To, że nie można polegać na systemie
wyjątków w PHP - to drugie.
Nie wiem dlaczego, wraz z wyjściem PHP5 nie dodali wyjątków do tych swoich
pokracznie nazwanych funkcji standardowych. Przecież wsteczną
kompatybilność mogliby zachować za pomocą jakiegoś switcha, który by je
włączał, lub nie. Widocznie za skomplikowane dla tych "miszczów".
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.
Stąd model obiektowy w PHP5 został napisany od podstaw!
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).
Wprowadzono do PHP zupełnie bezsensownie nieobiektowe konstrukcje w
postaci metod statycznych, interfejsów czy głupi podział na prymitywy i
obiekty. 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.
Moim zdaniem, ten język brnie w ślepy zaułek. 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, tracąc swój początgkowy
atut jakim była prostota. Jest coraz wolniejszy w stosunku do innych
języków dynamicznie typowanych.
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.
To prawda, że wciąż łatwiej znaleźć programistę PHP niż Ruby czy Pythona.
Jednak w tym wypadku ilość nie oznacza jakości.
--
JZ http://blog.zabiello.com
pakalk
> Dnia 31-10-2009 o 12:08:38 pakalk <pak...@gmail.com> napisał(a):
>
>
>
>
>
> >> function jakis_kod() { return null; }
> >> $obj = jakis_kod();
> >> $obj->jakas_metoda(); # hehe, php leży i kwiczy
>
> > Tak, racja. Tutaj jest do dupy. Da sie to wylapac, ale nie da sie
> > obsluzyc.
>
> > Ewentualnie...
>
> > function jakis_kod()
> > {
> > return null;
> > }
>
> > $obj = jakis_kod();
>
> > if ( $obj !== null )
> > {
> > $obj->jakas_metoda();
> > }
> > ;
>
> Prawda, jakie to wspaniałe, że w PHP trzeba sprawdzać wartość każdej
> zmiennej przed jej użyciem aby uniknąć kompletnego upadku całej aplikacji?
Nie no, nie kazdej. Zreszta to chyba nie nowosc, ze jezeli cos Ci moze
zwrocic rozne wartosci to sie to testuje.
> To, że to wygląda jak kupa to jedno.
Jak dla mnie to ify takie kupowate nie sa :P
> To, że nie można polegać na systemie
> wyjątków w PHP - to drugie.
Czemu nie mozna?
>
> 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.
> interfejsów
Interfejsy sa nieobiektowymi konstrukcjami?
> 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? :)
> 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.
>
> 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.
Marek Wywiał
>
> > To, że nie można polegać na systemie
> > wyjątków w PHP - to drugie.
>
> Czemu nie mozna?
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
pakalk
> 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ą
>
To co to ma wspolnego ze zlym systemem wyjatkow?
>
> Metoda statyczna, jest to metodą nie używająca właściwości obiektu w
> którym się znajduje,
Metody statyczne nie sa wlasnoscia obiektow, tylko klas.
> tylko np dodająca 2 wartości przekazane jako argumenty. A do tego
> służą funkcje odpowiednim
> namespace/pakiecie.
Albo w odpowiedniej klasie, ktroa w ten sposob agreguje funkcje.
> To nie jest standard OOP tylko proteza na
> upychanie funkcji w namespace klasy
> w Javie.
Powiedz to autorom UML, bo chyba o tym nie slyszeli, skoro zawarli to
w standardzie.
>
> W pythonie wystarczy umieścić funkcję w pakiecie, nie potrzeba do tego
> wymyślać klasy, w której
> chciałbym mieć tą funkcję.
To po co w pythonie sa metody klasowe i statyczne (inaczej dzialajace
niz w innych jezykach, bo nie w kontekscie klasy)?
>
> 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.
>
Twoim zdaniem. A moim zdaniem jest inaczej.
>
>
> > > 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.
>
Ok, musisz to powiedziec autorom UML. Znow. Chociaz po co - oni sie na
obiektowce w ogole nie znaja.
>
> Protected i private też nie należą do OOP tylko do konkretnej
> implementacji OOP.
Ech.. gadasz bez sensu. Enkapsulacja to podstawa programowania
obiektowego.
> Nie służą one do wymuszania ale do informowania o przeznaczeniu
> konkretnej właściwości.
Owszem, sluza do wymuszania uzywania/nieuzywania danych czlonkow klasy
w dany sposob. Nie wiem, czy Ty w ogole zdajesz sobie sprawe o czym
mowisz. Informowac to sobie mozesz w komentarzach.
>
> 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.
Zly model obiektowy - co z tego? Protected generalnie nie jest uzywane
poza miejscami, gdy klasy pochodne maja "skonfigurowac" dzialanie
klasy, ktorej generalny mechanizm zawarto w bazowej. Wtedy sie
sprawdzaja. W Pythonie (w dokumentacji chocby) widzialem metody
publiczne, ktore sa przeznaczone do nadpisania w klasach pochodnych.
One wlasnie powinny miec ustawiony modyfikator protected.
>
> Tworzy się wtedy obejście na niepotrzebne blokowanie przy pomocy klas
> friendly.
Nie wiem skad Ci sie wziely teraz klasy zaprzyjaznione.
>
> 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.
Z glupimi nazwami.
>
> Hermetyzacja nie oznacza blokowania klasy przed idiotami, tylko jasne
> oznaczenie przeznaczenia klas i ich elementów.
Owszem.
> 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).
Ok, ale co z tego?
Marek Wywiał
Starałem ci się pokazać, że w pythonie jaki w php enkapsulacja działa
i jest tak samo sprawna,
skoro piszesz 'Ok, ale co z tego?' czyli to widzisz i z tego tyle, że
mój wywód pomimo zmylonego objekt/klasa
na coś się przydał :)
pakalk
>
> > Ok, ale co z tego?
>
> Starałem ci się pokazać, że w pythonie jaki w php enkapsulacja działa
> i jest tak samo sprawna,
> skoro piszesz 'Ok, ale co z tego?' czyli to widzisz i z tego tyle, że
> mój wywód pomimo zmylonego objekt/klasa
> na coś się przydał :)
No dobra.. czyli teraz podumowujac
1. Model OOP w PHP jest do dupy
2. "w pythonie (...) jest tak samo sprawna"
Wszystko jasne ;)
Ja wcale nie twierdzilem, ze obiektowka pythonowa nie jest calkiem
bee. Da sie robic wiele wiele rzeczy, choc w dziwny niekiedy sposob
trzeba zapisywac te podstawowe. Python ma braki skladniowe w tej
kwestii, nadrabia dekoratorami (troche protezowo to wyglada), ale jak
wprowadzono klasy abstrakcyjne, to mozna ich smialo uzywac jak
interfejsow (przy wielokrotnym dziedziczeniu jest ok jak w C++).
Jaroslaw Zabiello
>> Jak dotąd przychodzi mi do głowy to, że:
>>
>> - sensownie zaprojektowane frameworki phpowe są w nowością
>> i nie umywają się dojrzałością, dokumentacją i ilością dodatków do
>> django
>
> Bzdura. Wystarczy spojrzeć na Symfony
Czy mi się tylko wydaje, czy ktoś faktycznie zapomniał wtej dyskusji
wspomnieć o tym, że Symfony jest koszmarnie wolne?
--
JZ http://blog.zabiello.com
Jaroslaw Zabiello
>> Prawda, jakie to wspaniałe, że w PHP trzeba sprawdzać wartość każdej
>> zmiennej przed jej użyciem aby uniknąć kompletnego upadku całej
>> aplikacji?
>
> Nie no, nie kazdej. Zreszta to chyba nie nowosc, ze jezeli cos Ci moze
> zwrocic rozne wartosci to sie to testuje.
Chyba sobie żartujesz. Właśnie w tym problem, że nie zawsze wszystko
przewidzisz. Gdyby PHP generował wyjątek, to można by to standardowo
przechwycić w wyższej warstwie i automatycznie obsłużyć. Po prostu do dupy
ten pehapowy design.
>> To, że to wygląda jak kupa to jedno.
>
> Jak dla mnie to ify takie kupowate nie sa :P
Tylko kto pisze w tak paranoidalny sposób testując każdą zmienną? Wyjątki
tu dużo uproszczają.
>> To, że nie można polegać na systemie wyjątków w PHP - to drugie.
>
> Czemu nie mozna?
Tego, że nie można w prosty i spójny sposób założyć pułapki na wszelkie,
możliwe błędy. Ani nie wychwycisz tym fatal errorów ani nie jesteś w
stanie wyłapać tą drogą błędów z funkcji wbudowanych, bo po prostu one nie
generują wyjątków. Niby dodali obsługę wyjątków tylko że mały z tego
pożytek.
>> 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.
Ta proteza pokazuje kompetencje programistycze tworców PHP.
>> Stąd model obiektowy w PHP5 został napisany od podstaw!
>
> Podobnie jak caly Zend Engine. A to zle?
Dobrze, że nie zostano przy modelu z PHP4. Źle, że musiano to robić od
zera po raz drugi wprowadzając zamieszanie do już istniejącego bajzlu w
PHP. I źle, że to zrobiono znowu kiepsko.
>> 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.
LOL!
>> 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.
W Pythonie to też jest bez sensu, zgoda (w Ruby i w Scali takich głupot
nie ma). Ale w Pythonie przynajmniej klasy są obiektami i nie trzeba w
ogóle używać tych metod statycznych bo do niczego nie są potrzebne.
Pythonowe ma metody klasowe.
> Interfejsy sa nieobiektowymi konstrukcjami?
Oczywiście że nie są. Już ci ktoś o tym napisał. Dodam jeszcze że
interfejsy są głupią konstrukcją. Znacznie lepsze są miksiny (jak w Ruby)
lub traits (jak w Scali) ktore z grubsza działają jak interfejsy z tą
różnicą że mogą posiadać częściową implementację. Interfejsy nie mogą mieć
żadnej implementacji. To jest ich główna wada.
>> czy głupi podział na prymitywy i obiekty.
>
> No fakt, ze latwiej ogarnac jedne typ zmiennych.
Ani nie można robić chain methods na stringach czy liczbach. Po co w
języku dynamicznym tak niskopoziomowe struktury? Bez sensu.
>> 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? :)
Ruby i Scala mają kwalifikatory dostępu :P Co do Pythona, to już ci
odpowiadziano, że to kwestia bardziej konwencji, a nie zabezpieczeń.
Kwalifikatory protected i private łatwo obejść w PHP:
http://blog.zabiello.com/2009/06/21/zabezpieczenia-protected-private-java-scala-php5.
>> Jest coraz wolniejszy w stosunku do innych języków dynamicznie
>> typowanych.
>
> To zalezy od implementacji, ale nie znam dobrych benchamarkow.
Jakie byś nie brał, PHP jest wolny. Szczególnie silnie to widać po
webowych frameworkach. Wszystkie są wolniejsze od dowolnego frameworka
napisanego w Ruby (Rails, Merb, Sinatra, Ramaze, etc.) czy Pythonie
(Django, Pylons, Tornado itp). A wspomniany wcześniej Symfony to chodzi
zupełnie jak żółw (Cake jest jeszcze wolniejszy!). Zresztą nic dziwnego.
To wynika z pehapowej specyfiki pracy w stylu cgi. Żaden akcelerator nie
zmieni tego, że PHP niszczy i tworzy na nowo obiekty przy każdym
requeście, a to kosztuje. Możnaby spróbować pisać w PHP w stylu
serwletowym, gdyby miał dobrą wielowątkowość i przede wszystkim wydajny
garbage collector. Niestey, nie ma tego pierwszego, a to drugie jest
kompletnie niedopracowane. Stąd im większy kod tym PHP bardziej odstaje
wydajnościwo w stosunku do framworków pracujących serwletowo.
>> 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.
Tylko skąd się bierze tyle konwertytów Javy do Ruby/JRuby? :) Java jest
językiem przestarzałym i ograniczonym. Ale ma dobrego Hotspota i kupę
ciekawszych języków zgodnych z JVM.
>> 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.
Myślę, że jest nawet mniej. Mało który dobry programista zostaje przy PHP.
Zresztą, nowoczesny programista musi być poliglotą, znać więcej niż jeden
język programowania. Takie czasy. A jak raz poznasz jakiś lepszy, to nie
będziesz chciał używać gorszego. Proste i logiczne. Ja np. używam PHP
tylko wtedy, kiedy muszę. Kiedy nie muszę, używam głównie JRuby. Prościej,
szybciej i wygodniej.
--
JZ http://blog.zabiello.com
pakalk
>
> >> To, że to wygląda jak kupa to jedno.
>
> > Jak dla mnie to ify takie kupowate nie sa :P
>
> Tylko kto pisze w tak paranoidalny sposób testując każdą zmienną? Wyjątki
> tu dużo uproszczają.
Jasne. Bo zamiast ifa, trzeba napisac try..catch - oczywiscie nie
badzmy paranoidalni - wowczas aplikacja staje i sprawdzamy w logach co
jest nie tak. Bo chyba nie wyswietlamy userowi komnunikatu z bledem?
>
> Tego, że nie można w prosty i spójny sposób założyć pułapki na wszelkie,
> możliwe błędy.
Ale co to ma wspolnego z systemem wyjatkow? To jest system obslugi
bledow.
>
> >> 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.
>
> Ta proteza pokazuje kompetencje programistycze tworców PHP.
W PHP4, nie aktualnej i jedynej wspieranej wersji, czyli PHP5. W PHP3
w ogole obiektowki nie bylo - i co? To tez mamy krytykowac? To moze
dorzucmy cos z PHP/FI, co co prawda nie ma juz nic wspolnego z
rzeczywistoscia, ale fajnie tak dowalic, byle dowalic ;)
> Dobrze, że nie zostano przy modelu z PHP4. Źle, że musiano to robić od
> zera po raz drugi wprowadzając zamieszanie do już istniejącego bajzlu w
> PHP. I źle, że to zrobiono znowu kiepsko.
Czy kiepsko, to nie wiem. Ale jak dobrze zrobiono, to o co chodzi?
>
> LOL!
Obiektowy model Javy jest swiatowym standardem - tu nie ma nic do
smiania.
>
> W Pythonie to też jest bez sensu, zgoda (w Ruby i w Scali takich głupot
> nie ma).
W skali nie ma metod statycznych? Pierwsze slysze. Toz to chocby main
() jest statyczny. Co z tego, ze klase z metodami statyczna nazywa sie
"object".
> Ale w Pythonie przynajmniej klasy są obiektami i nie trzeba w
> ogóle używać tych metod statycznych bo do niczego nie są potrzebne.
Nie trzeba uzywac, bo mozna zdefiniowac funkcje w modulach. Jakby sie
nie dalo, to by trzeba jako metdoy statyczne, coby je zagregowac. Poza
tym, to jest chyba jednak pozyteczne z tego wzgledu, ze mozna wtedy
uzyc metod prywatnych w metodach publicznych - da sie tak zrobic z
funkcjami? (Tzn. ustawic ich modyfikator na private? Nie znam sie na
tyle - wiec pytam)
> Pythonowe ma metody klasowe.
1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np. Javie)
2. Metoda statyczna w pythonie == funkcja przyczepiona do klasy, nie
uruchamiana w jej kontekscie.
>
> > Interfejsy sa nieobiektowymi konstrukcjami?
>
> Oczywiście że nie są. Już ci ktoś o tym napisał.
Co z tego, ze napisal. Ja pisze, ze sa. Autorzy UML-a mnie popra.
> Dodam jeszcze że
> interfejsy są głupią konstrukcją. Znacznie lepsze są miksiny (jak w Ruby)
To inna konstrukcja, a nie lepsza i raczej przypominajaca inline'owe
klasy abstrakcyjne, ale nie pamietam dobrze, nie pisze na 100%.
> lub traits (jak w Scali) ktore z grubsza działają jak interfejsy z tą
> różnicą że mogą posiadać częściową implementację.
Dzialaja jak (m/w) klasy abstrakcyjne. Nie wiem po co w Scali tyle
glupawych nazw.
> Interfejsy nie mogą mieć
> żadnej implementacji. To jest ich główna wada.
To jest ich cecha, a nie wada. Fakt, ze klasy abstrakcyjne/wirtualne
przy dziedziczeniu wielokrotnym moga sie lepiej sprawdzac.
>
> > Tzn. pythona bez podstawowego modyfikatora protected i __protezy dla
> > private? :)
>
> Ruby i Scala mają kwalifikatory dostępu :P Co do Pythona, to już ci
> odpowiadziano, że to kwestia bardziej konwencji, a nie zabezpieczeń.
No to moge kazdy argument przeciw PHP zbywac tym, ze to kwestia
konwencji, bo tak jest.
>
> >> Jest coraz wolniejszy w stosunku do innych języków dynamicznie
> >> typowanych.
>
> > To zalezy od implementacji, ale nie znam dobrych benchamarkow.
>
> Jakie byś nie brał, PHP jest wolny. Szczególnie silnie to widać po
> webowych frameworkach. Wszystkie są wolniejsze od dowolnego frameworka
> napisanego w Ruby (Rails, Merb, Sinatra, Ramaze, etc.) czy Pythonie
> (Django, Pylons, Tornado itp). A wspomniany wcześniej Symfony to chodzi
> zupełnie jak żółw (Cake jest jeszcze wolniejszy!).
Mozliwe.
>
> > Ci, ktorzy sie podszkola wola jave.
>
> Tylko skąd się bierze tyle konwertytów Javy do Ruby/JRuby? :) Java jest
> językiem przestarzałym i ograniczonym. Ale ma dobrego Hotspota i kupę
> ciekawszych języków zgodnych z JVM.
Java nie jest taka zla. Po prostu jest sztywna ;) JRuby/Jython
zapewniaja standaryzowana skryptowosc aplikacji, co czesto bywa
bardziej pozadane od silnego typowania (choc z dobrymi narzedziami do
tworzenia aplikacji, to roznie..).
>
> > Co tez nie znaczy, ze dobrych programistow PHP jest mniej niz Pythona
> > czy Ruby.
>
> Myślę, że jest nawet mniej. Mało który dobry programista zostaje przy PHP.
> Zresztą, nowoczesny programista musi być poliglotą, znać więcej niż jeden
> język programowania. Takie czasy. A jak raz poznasz jakiś lepszy, to nie
> będziesz chciał używać gorszego. Proste i logiczne. Ja np. używam PHP
> tylko wtedy, kiedy muszę. Kiedy nie muszę, używam głównie JRuby. Prościej,
> szybciej i wygodniej.
Czemu nie Jython?
Grzegorz Staniak
>> >> To, że to wygląda jak kupa to jedno.
>>
>> > Jak dla mnie to ify takie kupowate nie sa :P
>>
>> Tylko kto pisze w tak paranoidalny sposób testując każdą
>> zmienną? Wyjątki tu dużo uproszczają.
>
> Jasne. Bo zamiast ifa, trzeba napisac try..catch - oczywiscie nie
> badzmy paranoidalni - wowczas aplikacja staje i sprawdzamy w logach
> co jest nie tak.
Czy do ciebie w ogóle dociera sens tego co czytasz? Piszesz
"try...catch" a "wowczas aplikacja staje i sprawdzamy w logach
co jest nie tak"? Chciałeś podkreślić kompromitację PHP w zakresie
obsługi błedów, czy usiłowałeś go bronić, a wyszło jak zwykle?
pakalk
>
> Czy do ciebie w ogóle dociera sens tego co czytasz? Piszesz
> "try...catch" a "wowczas aplikacja staje i sprawdzamy w logach
> co jest nie tak"? Chciałeś podkreślić kompromitację PHP w zakresie
> obsługi błedów, czy usiłowałeś go bronić, a wyszło jak zwykle?
>
Napisze tylko jeszcze raz: dr House... albo nie, bo dzis swieto.
Oczywiscie, ze pisalem, ze aplikacja staje, gdy nie jestesmy
paranoidalni i tak samo jak nie bedziemy testowac ifem, nie napiszemy
try..catch.
pakalk
mylę się?
class ProtTest:
_x = "Zmienna chroniona?"
def _foo( self ):
return "Funkcja chroniona?"
o = ProtTest()
print o._x
print o._foo()
Nie opowiadajcie mi, ze konwencja nazewnictwa to wsparcie jezyka w
jakims aspekcie obiektowosci, bo to smieszne jest (a i przypomina
opowiadania perlowcow o fajnosci ich idiotycznych sigilow i twigilow
przed zmiennymi). Owszem - protected i private nie uzywa sie, zeby
komus zrobic na zlosc, ale zeby pomoc/poinformowac/ukryc czesc kodu,
ktorej nie piszemy dla publicznosci. Nie ma to jednak znaczenia, gdy
rozmawiamy o wsparciu ze storny jezyka - a python nie wspiera metod/
atrybutow chronionych.
Grzegorz Staniak
>> Czy do ciebie w ogóle dociera sens tego co czytasz? Piszesz
>> "try...catch" a "wowczas aplikacja staje i sprawdzamy w logach
>> co jest nie tak"? Chciałeś podkreślić kompromitację PHP w
>> zakresie obsługi błedów, czy usiłowałeś go bronić, a wyszło
>> jak zwykle?
>
> Napisze tylko jeszcze raz: dr House... albo nie, bo dzis swieto.
> Oczywiscie, ze pisalem, ze aplikacja staje, gdy nie jestesmy
> paranoidalni i tak samo jak nie bedziemy testowac ifem, nie
> napiszemy try..catch.
> Jasne. Bo zamiast ifa, trzeba napisac try..catch - oczywiscie
> nie badzmy paranoidalni - wowczas aplikacja staje i sprawdzamy
> w logach co jest nie tak.
I to ma według ciebie z powyższego wynikać? Bez żartów. Marna
wymówka.
Różnica między PHP a normalnym językiem jest taka, że w tym drugim
nie muszę być "paranoidalny": mogę być leniuszkiem i wyłapywać wyjątki
raz dla całego bloku kodu, a nie pojedynczych zmiennych. I mimo to mieć
obsłużoną przez wyższe warstwy każdą wyjątkową sytuację. Pehap jak zwykle
dodał do języka trochę składni -- to jest panaceum autorów tego języka:
dokleić do istniejącej zbieraniny taśmą klejącą kolejny kawałek, o który
się jakieś nerdy burzą -- ale nie zapewnił niczego, na czym można byłoby
polegać: kod "legacy" wyjątków nie rzuca, nowy kod nie wyłapuje jak
trzeba i efekt jest jak zwykle w pehapie: masturbacja nowym wspaniałym
ficzerem, który jest nieużywalny, a obsługa błędów nadal sprowadza się
do grzebania w logach.
pakalk
> On 01.11.2009, pakalk <pak...@gmail.com> wroted:
>
> >> Czy do ciebie w ogóle dociera sens tego co czytasz? Piszesz
> >> "try...catch" a "wowczas aplikacja staje i sprawdzamy w logach
> >> co jest nie tak"? Chciałeś podkreślić kompromitację PHP w
> >> zakresie obsługi błedów, czy usiłowałeś go bronić, a wyszło
> >> jak zwykle?
>
> > Napisze tylko jeszcze raz: dr House... albo nie, bo dzis swieto.
> > Oczywiscie, ze pisalem, ze aplikacja staje, gdy nie jestesmy
> > paranoidalni i tak samo jak nie bedziemy testowac ifem, nie
> > napiszemy try..catch.
>
> > Jasne. Bo zamiast ifa, trzeba napisac try..catch - oczywiscie
> > nie badzmy paranoidalni - wowczas aplikacja staje i sprawdzamy
> > w logach co jest nie tak.
>
> I to ma według ciebie z powyższego wynikać? Bez żartów. Marna
> wymówka.
Ok, jednak napisze: jestes idiota.
Grzegorz Staniak
No skoro nie pozostało ci nic innego, byłbym okrutny odmawiając
ci ucieczki z wątku.
I jeszcze ad rem, żeby jednak zostało w archiwum Google Groups:
pokazana analogia jest nieprawdziwa -- gdyby pehap miał dobrze
zaimplementowaną obsługę błędów, "try...catch" mogłoby
obejmować całe bloki kodu, nikt nie musiałby być "paranoidalny"
jeśli miałby ochotę być leniwy, a wyższe warstwy aplikacji mimo
to mogłyby obsłużyć każdą wyjątkową sytuację. Postulowanie,
że bez "paranoidalności" to i tak na jedno wychodzi wynika
wyłącznie z kompromitującej obsługi wyjątków w tym języku.
Innymi słowy: usiłowałeś go bronić, ale jednak wyszło jak zwykle.
Jaroslaw Zabiello
> Poza tym, to nie ma nic takiego jak protected, przynajmniej w Py2.6 -
> mylę się?
>
> class ProtTest:
> _x = "Zmienna chroniona?"
>
> def _foo( self ):
> return "Funkcja chroniona?"
>
> o = ProtTest()
>
> print o._x
> print o._foo()
Tylko, że tak będzie pisał tylko ktoś kto nie ma pojęcia o Pythonie. Każdy
pythonista dobrze wie, że nie należy wywoływać tak nazwanych atrybutów
jakby to były atrybuty publiczne. Każdy (po nazwie) od razu widzi, że to
nie jest atrybut publiczny i po prostu tak się to traktuje. To wszystko
kwestia umowy. Ale aby to wiedzieć, trzeba wpierw chociaż poczytać sobie o
Pythonie i jego założeniach (btw, klas też się tak od dawna nie tworzy
tak, jak w twym przykładzie).
Te wszystkie kwalifikatory protected i private to kwestia konwencji. W
Pythonie wszystkie atrybuty są publiczne z definicji. Co nie znaczy, że
można przez pomyłkę coś nadpisać. Nie, trzeba to chcieć, zrobić celowo.
Np.
>>> class ProtTest(object):
... __x = "Zmienna prywatna"
...
>>> o = ProtTest()
>>> o.__x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'ProtTest' object has no attribute '__x'
>>> o._ProtTest__x
'Zmienna prywatna'
Z drugiej strony, jak ktoś chce, to w PHP5 też łatwo uzyska dostęp do jego
"atrybutów chronionych":
<?php
class ProtTest {
private $priv = "Zmienna prywatna?";
protected $prot = "Zmienna chroniona?";
}
$o = new ProtTest();
$a = (array)$o;
print $a["\0ProtTest\0priv"]; # => Zmienna prywatna?
print $a["\0*\0prot"]; # => Zmienna chroniona?
?>
Więc, nie rozumiem tu twojej krytyki Pythona. Poza tym upada ona zupełnie
przy Ruby, który posiada te kwalifikatory dostępu.
--
JZ http://blog.zabiello.com
Jaroslaw Zabiello
>> Tylko kto pisze w tak paranoidalny sposób testując każdą zmienną?
>> Wyjątki tu dużo uproszczają.
>
> Jasne. Bo zamiast ifa, trzeba napisac try..catch
Tylko, że aby ci pehap nie padł na twarz, to te nieszczęsne ify musisz
wpieprzać przy każdej zmiennej. Natomiast blok try-catch używasz dużo
rzadziej, bo może obejmować sobą dowolną ilość linii kodu. Kolega Grzegorz
próbował ci to wytłumaczyć...
> badzmy paranoidalni - wowczas aplikacja staje i sprawdzamy w logach co
> jest nie tak.
Jak to aplikacja staje? Staje tylko przy fatal errorze, to tylko PHP
staje. Python, Ruby czy Scala nigdy nie musi stanąć, bo po prostu można
przechwycić wyjątek i go obsłużyć.
> Bo chyba nie wyswietlamy userowi komnunikatu z bledem?
Z błędem - nie. Ale o błędzie - tak (lub dowolną ściemę do wyboru)
>> nie można w prosty i spójny sposób założyć pułapki na wszelkie, możliwe
>> błędy.
>
> Ale co to ma wspolnego z systemem wyjatkow? To jest system obslugi
> bledow.
Ano jest. Django i web2py automatycznie obsłużą ci wszelkie błędy i ładnie
to zgłoszą programistom. Użyszkodnik zaś może dostać jakiś sensowny
komunikat, a nie pustą stronę, czy techniczną informację o fatal errorze w
jakimś pliku. W PHP byle fatal error, cała aplikacja leży i kwiczy o czym,
niestety, można się dowiedzieć tylko *po faktach* w plikach z logiem.
>> Ta proteza pokazuje kompetencje programistycze tworców PHP.
>
> W PHP4, nie aktualnej i jedynej wspieranej wersji, czyli PHP5.
Masz na myśli PHP 5.2 czy 5.3, bo w 5.3 znowu pozmieniali coś w modelu
obiektowym. LOL!
> Obiektowy model Javy jest swiatowym standardem - tu nie ma nic do
> smiania.
Ależ jest. Każdy wie, że model obiektowy Javy jest daleki od doskonałości.
A słyszałeś o tej reklamie, że milion much jedzących gówno nie może się
mylić? Jedz więc...
>> W Pythonie to też jest bez sensu, zgoda (w Ruby i w Scali takich głupot
>> nie ma).
>
> W skali nie ma metod statycznych? Pierwsze slysze. Toz to chocby main
> () jest statyczny. Co z tego, ze klase z metodami statyczna nazywa sie
> "object".
Po pierwsze, nie "skali", ale Scali. Po drugie, to nie są żadne metody
statyczne, ale klasowe, tj. singletony. W Scali nie ma żadnych metod
statycznych, nie ma interfejsów, i nie ma podziału na obiekty i typy
prymitywne.
> Pozatym, to jest chyba jednak pozyteczne z tego wzgledu, ze mozna wtedy
> uzyc metod prywatnych w metodach publicznych
Co proszę? Metody statyczne, to nie żadne metody publiczne, to nie są
żadne metody, to są funkcje nie związane w ogóle z obiektem. Nie mają
żadnego dostępu do bebechów obiektu. Poza tym metody statycznej nie
poślesz z klasą jako parametr.
object A {
def foo = println("foo")
}
val a = A
a.foo
> 1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np. Javie)
Nie. Klasa w Pythonie jest obiektem a metoda klasowa jest jej singletonem.
>>> Interfejsy sa nieobiektowymi konstrukcjami?
>>
>> Oczywiście że nie są. Już ci ktoś o tym napisał.
>
> Co z tego, ze napisal. Ja pisze, ze sa.
Eee tam. A jakiś argument dorzucisz czy mam poprzestać na twojej
deklarację wiary? Ale nie chodzi o spór o słowa. Interfejsy są po prostu
do dupy. Z def. nie mogą posiadać żadnej implementacji. To jest ich główna
wada.
> Autorzy UML-a mnie popra.
A co mnie obchodzi jakiś UML? Mogą sobie robić diagramy z czegokolwiek,
nawet z fusów. Czy zmienią to, że Java nie jest językiem w pełni
obiektowym?
>> Dodam jeszcze że interfejsy są głupią konstrukcją. Znacznie lepsze są
>> miksiny (jak w Ruby)
>
> To inna konstrukcja, a nie lepsza i raczej przypominajaca inline'owe
> klasy abstrakcyjne, ale nie pamietam dobrze, nie pisze na 100%.
Oczywiście że miksiny są lepsze. Pozwalają na budowanie modułów bez
niepotrzebnej duplikacji kodu. To nie są żadne klasy abstrakcyjne, bo nie
mogą mieć swojej instancji i nie mają konstruktorów. W Ruby można je
domieszkować do klas jako metody instancji lub klasowe, lub obie naraz,
wedle uznania.
>> lub traits (jak w Scali) ktore z grubsza działają jak interfejsy z tą
>> różnicą że mogą posiadać częściową implementację.
>
> Dzialaja jak (m/w) klasy abstrakcyjne. Nie wiem po co w Scali tyle
> glupawych nazw.
Nie, traitsy są o wiele bardziej ogólne.
Po pierwsze, klasa może domieszkować wiele traitsów. A nie możesz
dziedziczyć po wielu klasach abstrakcyjnych, tylko po jednej.
Po drugie, traitsy mają możliwośc linearyzacji, czyli masz możliwość
wpływu na kolejność w jakiej zostaną wywołane super w kolejnych cechach.
Np.
object foo extends AnyRef { override def toString = "foo" }
trait A { def foo }
trait Log extends A {
override abstract def foo = {
println("pre log")
super.foo
println("post log")
}
}
trait Transaction extends A {
override abstract def foo = {
println("pre transaction")
super.foo
println("post transaction")
}
}
class C { def foo = println("implementacja") }
val c = new C with Log with Transaction
c.foo
>> Interfejsy nie mogą mieć żadnej implementacji. To jest ich główna wada.
>
> To jest ich cecha, a nie wada.
Cecha, która jest równocześnie ich wadą.
> Fakt, ze klasy abstrakcyjne/wirtualne
> przy dziedziczeniu wielokrotnym moga sie lepiej sprawdzac.
Klasy abstrakcyjne są do bani, bo nie można dziedziczyć po kilku klasach
abstrakcyjnych. To duże ograniczenie. Można dziedziczyć po wielu
interfejsach, ale z kolei te nie moga mieć żadnej implementacji. I tak
źle, i tak niedobrze. Gówniany model po prostu.
>> > Tzn. pythona bez podstawowego modyfikatora protected i __protezy dla
>> > private? :)
>>
>> Ruby i Scala mają kwalifikatory dostępu :P Co do Pythona, to już ci
>> odpowiadziano, że to kwestia bardziej konwencji, a nie zabezpieczeń.
>
> No to moge kazdy argument przeciw PHP zbywac tym, ze to kwestia
> konwencji, bo tak jest.
Jakiej znowu konwencji? Nie dające się obsłużyć fatal errory to kowencja?
Nie bądź śmieszny.
> Java nie jest taka zla. Po prostu jest sztywna ;)
I taka jest celowo. Nie ma sensu jej odsztywniać. Jest Scala.
> JRuby/Jython zapewniaja standaryzowana skryptowosc aplikacji, co czesto
> bywa
> bardziej pozadane od silnego typowania (choc z dobrymi narzedziami do
> tworzenia aplikacji, to roznie..).
Klasy JRuby i Jythona nie są (jeszcze) klasami Javy co umożliwia bardziej
przezroczyste połączenie z kodem Javy (tak jak to jest w Scali, Cojure czy
Groovy). Np. jak byś chciał użyć obiektowej bazy danych (np. Neodatis) to
nie możesz w JRuby stworzyć definicji klas. Ale to się zmieni, bo trwają
prace aby klasy JRuby były gtakże klasami Javy.
> Czemu nie Jython?
JRuby jest dojrzalszy, szybszy, ładniejszy. Poza tym ma wygodniejszy i
ładniejszy DSL do testów (RSpec/Cucumber & AutoTest), lepsze narzędzia do
pisania tasków (Rake), lepszy, łatwiejszy system zarządzania bibliotekami
(RubyGems vs. setuptools), ma lepszy IDE do Rails (RubyMine) niże
cokolwiek do Django czy Pylons, itp. itd.
--
JZ http://blog.zabiello.com
Jaroslaw Zabiello
> 1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np. Javie)
Akurat. Metody statycznej nie przesłonisz, a klasową - tak.
--
JZ http://blog.zabiello.com
Marek Wywiał
> > > Interfejsy sa nieobiektowymi konstrukcjami?
>
> > Oczywiście że nie są. Już ci ktoś o tym napisał.
>
> Co z tego, ze napisal. Ja pisze, ze sa. Autorzy UML-a mnie popra.
Autorów UML nie obchodzi to, iż piszesz, że są. Jak jest inaczej to
podeślij notkę od nich w tej sprawie.
UML jest językiem opisu, czyli opisuje istniejący świat, a nie tworzy
go czy definiuje.
Sam interfejs może być do pakietu, modułu ew. klasy lub czegoś innego
i możesz to sobie ładnie narysować
w UML, jednak nie ma to związku ze słowem kluczowym Interface w PHP
czy Java.
Brzmi to tak jakby w UML miał powstać specjalny diagram dla 'def', i
inny dla 'function'.
pakalk
> Dnia 01-11-2009 o 20:00:29 pakalk <pak...@gmail.com> napisał(a):
>
> > Poza tym, to nie ma nic takiego jak protected, przynajmniej w Py2.6 -
> > mylę się?
>
> > class ProtTest:
> > _x = "Zmienna chroniona?"
>
> > def _foo( self ):
> > return "Funkcja chroniona?"
>
> > o = ProtTest()
>
> > print o._x
> > print o._foo()
>
> Tylko, że tak będzie pisał tylko ktoś kto nie ma pojęcia o Pythonie. Każdy
> pythonista dobrze wie, że nie należy wywoływać tak nazwanych atrybutów
> jakby to były atrybuty publiczne.
Otóż to właśnie jest brak wsparcia ze strony języka. Już zresztą
pisałem.
> Każdy (po nazwie) od razu widzi, że to
> nie jest atrybut publiczny i po prostu tak się to traktuje. To wszystko
> kwestia umowy. Ale aby to wiedzieć, trzeba wpierw chociaż poczytać sobie o
> Pythonie i jego założeniach (btw, klas też się tak od dawna nie tworzy
> tak, jak w twym przykładzie).
W tych założeniach nie ma wsparcia dla protected. I tyle. Po co
udawać, że jest?
>
> Te wszystkie kwalifikatory protected i private to kwestia konwencji.
Jakby tak było, toby błędami nie sypało.
> W
> Pythonie wszystkie atrybuty są publiczne z definicji. Co nie znaczy, że
> można przez pomyłkę coś nadpisać. Nie, trzeba to chcieć, zrobić celowo.
Wcale nie twierdzę, że nie.
> Np.
>
> >>> class ProtTest(object):
>
> ... __x = "Zmienna prywatna"
> ...>>> o = ProtTest()
> >>> o.__x
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> AttributeError: 'ProtTest' object has no attribute '__x'>>> o._ProtTest__x
>
> 'Zmienna prywatna'
>
> Z drugiej strony, jak ktoś chce, to w PHP5 też łatwo uzyska dostęp do jego
> "atrybutów chronionych":
>
> <?php
> class ProtTest {
> private $priv = "Zmienna prywatna?";
> protected $prot = "Zmienna chroniona?";}
>
> $o = new ProtTest();
> $a = (array)$o;
> print $a["\0ProtTest\0priv"]; # => Zmienna prywatna?
> print $a["\0*\0prot"]; # => Zmienna chroniona?
> ?>
>
> Więc, nie rozumiem tu twojej krytyki Pythona. Poza tym upada ona zupełnie
> przy Ruby, który posiada te kwalifikatory dostępu.
Nie do końca mnie rozumiesz. To nie jest kwestia krytyki pythona. Ja
po prostu stwierdzam fakt. Jeśli się ktoś rzuca na protected PHP, to
niech zauważy, że w Pythonie nie trzeba "atakować" tej formy
nkapsulacji, bo jej nie ma. Umówić można się na cokolwiek, ale to nie
jest wsparcie języka w danym problemie.