🚀 go-pugleaf

At Sun, 25 Oct 2009 21:36:58 +0100, chester wrote:

> 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 ;)

-- 
Radomir Dopieralski, http://sheep.art.pl

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

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

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:
 * 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ą.

On 29 Paź, 08:44, Marek Wywiał <onj...@gmail.com> wrote:
> 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:
>  *http://svn.symfony-project.com/branches/1.2/data/web/sf/sf_admin/js/c...

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?

Dnia 29-10-2009 o 10:05:29 pakalk <pakalk@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.

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

On Oct 31, 7:02 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> 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();
}

;)

Dnia 31-10-2009 o 12:08:38 pakalk <pakalk@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?

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

On Oct 31, 8:33 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> 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.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

On Oct 31, 10:17 pm, Marek Wywiał <onj...@gmail.com> wrote:
> 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?

On 31 Paź, 22:44, pakalk <pak...@gmail.com> wrote:
> On Oct 31, 10:17 pm, Marek Wywiał <onj...@gmail.com> wrote:
>
>
>
>
>
> > 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?

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ł :)

On Oct 31, 10:51 pm, Marek Wywiał <onj...@gmail.com> wrote:
>
> > 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++).

Dnia 31-10-2009 o 19:54:08 pakalk <pakalk@gmail.com> napisał(a):

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

On Nov 1, 6:48 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> >> 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?

On 01.11.2009, pakalk <pakalk@gmail.com> wroted:

>> >> 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?

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 1, 8:23 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
>
> 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.

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()

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.

On 01.11.2009, pakalk <pakalk@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.

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.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 1, 9:05 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> 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.

On 01.11.2009, pakalk <pakalk@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.

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.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

Dnia 01-11-2009 o 20:00:29 pakalk <pakalk@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. 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

Dnia 01-11-2009 o 19:14:22 pakalk <pakalk@gmail.com> napisał(a):

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

On 1 Lis, 20:14, pakalk <pak...@gmail.com> wrote:
> > > 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'.

On Nov 2, 12:28 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> 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.

On 2 Lis, 08:40, pakalk <pak...@gmail.com> wrote:
> On Nov 2, 12:28 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
>
>
>
>
> > 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.

Wydaje mi się, że mylisz pojęcie ze słowem kluczowym. To, że
właściwość
jest protected to pojęcie, a słowo kluczowe 'protected' lub '__' to
już kwestia użytej implementacji.

Podobnie myśląć, Python nie ma wsparcia dla funkcji bo nie ma słowa
kluczowego 'function' tylko 'def'.
Problem z rozumieniem obiektowości i innych pojęć wynika z
implementacji od której zaczyna się naukę.
Jakies 4-5 lat pewnie też bym się upierał przy 'protected' gdyż słowo
kluczowe i pojęcie było dla mnie tym samym.

Po poznaniu lepiej pythona i kilku innych odmiennych języków zacząłem
odróżniać jedno od drugiego.

On 2 Lis, 02:31, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> Dnia 01-11-2009 o 19:14:22 pakalk <pak...@gmail.com> napisał(a):
>
> >> 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.

1. Nie muszę każdej zmiennej - to jakieś totalne nieporozumienie
2. Potem nie trzeba testować jaki wyjątek nam wyskoczył? Ciekawe.

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

Pisze o sytuacji, gdy nie zostanie przechwycony

>
> > Bo chyba nie wyswietlamy userowi komnunikatu z bledem?
>
> Z błędem - nie. Ale o błędzie - tak (lub dowolną ściemę do wyboru)

jw.

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

Ok.

>
> >> 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!

5.3

Co pozmieniali?

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

Twórcy UML-a też pewnie jedzą. Czemu o nich nic nie piszesz? ;>

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

Nie czepiajmy się zapisu

> Po drugie, to nie są żadne metody  
> statyczne, ale klasowe, tj. singletony.

Metoda klasowa to metoda statyczna. Wystarczy spojrzeć na UML i kod
generowany potem w javie.

> W Scali nie ma żadnych metod  
> statycznych, nie ma interfejsów, i nie ma podziału na obiekty i typy  
> prymitywne.

Po co mieszasz rozne zagadnienia?

Interfejsow nie ma.
Prymitywow nie ma.
Ale metody statyczne/klasowe sa - co z tego, ze inaczej je nazwiemy?

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

Nie slyszales o prywatnych metodach statycznych?

>
> > 1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np. Javie)
>
> Nie. Klasa w Pythonie jest obiektem a metoda klasowa jest jej singletonem.

Mowie o zachowaniu a nie jego realzacji. I sie tak zachowuje.

>
> >>> 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?

Chcesz porozmawiac o kreacjonizmie? ;>

Czemu ja mam rzucac argumentami, skoro wystarczy spojrzec na UML,
ktory interfejsy zawiera w specyfikacji?

> 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?

UML jest opisem modelu obiektowego stworzonym przez ludzi, ktorzy
znaja sie na rzeczy lepiej ode mnie, czy Ciebie, wiec...


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

I lepsze i w ogole jazzy.

>
> Po pierwsze, klasa może domieszkować wiele traitsów. A nie możesz  
> dziedziczyć po wielu klasach abstrakcyjnych, tylko po jednej.

Kwestia dziedziczenia wielokrotnego a nie klas abstrakcyjnych. Gdyby
pozwolic na dziedziczenie wielokrotne w javie, to mozna uzyc
abstrakcyjnych.

> > To jest ich cecha, a nie wada.
>
> Cecha, która jest równocześnie ich wadą.

Cecha najnowszego modelu BMW jest to, ze nie jest amfibia. Dla Ciebie
to moze byc tez wada, dla innych niekoniecznie.

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

To nie jest cecha klas abstrakcyjnych, tylko realizacji przez jezyk. W
Pythonie mozna chyba?

Użytkownik "Marek Wywiał" <onjinx@gmail.com> napisał w wiadomości 
news:e470baee-ad72-4b96-8eb9-ae83daf479fb@d21g2000yqn.googlegroups.com...
On 1 Lis, 20:14, pakalk <pak...@gmail.com> wrote:
> > > 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.

> UML jest językiem opisu, czyli opisuje istniejący świat, a nie tworzy go 
> czy definiuje.

Dodajmy jeszcze, że sami twórcy UMLa nie ukrywają, że tworzyli go myśląc o 
zastosowaniach w Javie.

On 2 Lis, 08:13, Marek Wywiał <onj...@gmail.com> wrote:
> On 1 Lis, 20:14, pakalk <pak...@gmail.com> wrote:
>
> > > > 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.

1 warning.

>
> UML jest językiem opisu, czyli opisuje istniejący świat, a nie tworzy
> go czy definiuje.

Opisuje za pomoca modelu obiektowego.

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

Nie wcale, bo UML nie powstawal w oparciu o doswiadczenia z java.

>
> Brzmi to tak jakby w UML miał powstać specjalny diagram dla 'def', i
> inny dla 'function'.

Co Ty chrzanisz? Normalnie w UML sa interfejsy i maja swoje cechy,
ktore dziwnym trafem sa takie same jak cechy interfejsow w javie. Ale
nie, to nie sa obiektowe konstrukcje.

On 2 Lis, 08:51, Marek Wywiał <onj...@gmail.com> wrote:
> On 2 Lis, 08:40, pakalk <pak...@gmail.com> wrote:
>
>
>
> > On Nov 2, 12:28 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> > > 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.
>
> Wydaje mi się, że mylisz pojęcie ze słowem kluczowym. To, że
> właściwość
> jest protected to pojęcie, a słowo kluczowe 'protected' lub '__' to
> już kwestia użytej implementacji.

__ to private a nie protected. I nic nie myle.

>
> Podobnie myśląć, Python nie ma wsparcia dla funkcji bo nie ma słowa
> kluczowego 'function' tylko 'def'.

Nie.

> Problem z rozumieniem obiektowości i innych pojęć wynika z
> implementacji od której zaczyna się naukę.
> Jakies 4-5 lat pewnie też bym się upierał przy 'protected' gdyż słowo
> kluczowe i pojęcie było dla mnie tym samym.

Znowu mam ochote zacytowac House'a.


Czytales co pisalem o _? Czy sobie nie zadales trudu? Czy gdzies
napisalem, ze ma pisac "protected"? Niech i pisze "unprotected", ale
niech dziala, to wtedy bedzie wsparcie jezyka.

>
> Po poznaniu lepiej pythona i kilku innych odmiennych języków zacząłem
> odróżniać jedno od drugiego.

Gratuluje, ze dopiero wtedy. Masz sie czym chwalic.

On 02.11.2009, pakalk <pakalk@gmail.com> wroted:

>> >> 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.
>
> 1. Nie muszę każdej zmiennej - to jakieś totalne nieporozumienie
> 2. Potem nie trzeba testować jaki wyjątek nam wyskoczył?

Niczego nie trzeba testować, jeśli nie masz takiej ochoty. Wyższa
warstwa może po prostu przejąć _dowolny_ wyjątek i np. zgłosić 
userowi, albo zignorować. No i nie ma, jak w pehapie, zagrożenia 
padem aplikacji z fatal errorem mimo użycia instrukcji przechwytywania
wyjątku, ani potrzeby grzebania w logach.

Brniesz w tę głupotę z uporem godnym lepszej sprawy. Fatal errory 
pomimo "try...catch" i _braku_ błędu składniowego to jest kompromitacja 
obsługi wyjątków w PHP, kropka. 

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On 2 Lis, 09:25, pakalk <pak...@gmail.com> wrote:
> On 2 Lis, 08:51, Marek Wywiał <onj...@gmail.com> wrote:
>
>
>
>
>
> > On 2 Lis, 08:40, pakalk <pak...@gmail.com> wrote:
>
> > > On Nov 2, 12:28 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> > > > 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.
>
> > Wydaje mi się, że mylisz pojęcie ze słowem kluczowym. To, że
> > właściwość
> > jest protected to pojęcie, a słowo kluczowe 'protected' lub '__' to
> > już kwestia użytej implementacji.
>
> __ to private a nie protected. I nic nie myle.
>
>
>
> > Podobnie myśląć, Python nie ma wsparcia dla funkcji bo nie ma słowa
> > kluczowego 'function' tylko 'def'.
>
> Nie.
>
> > Problem z rozumieniem obiektowości i innych pojęć wynika z
> > implementacji od której zaczyna się naukę.
> > Jakies 4-5 lat pewnie też bym się upierał przy 'protected' gdyż słowo
> > kluczowe i pojęcie było dla mnie tym samym.
>
> Znowu mam ochote zacytowac House'a.

Cytuj, House nazywa idiotami wszystkich, którzy się z nim nie
zgadzają, nawet jeśli on sam nie ma racji, gdyż widzi tylko swój
światek.
Ale on po fakcie przyznaje się, że się mylił. Też docierasz do tego
etapu?

Z drugiej strony, jeżeli w dyskusji o programowaniu nie jesteś w
stanie zacytować żadnego autorytetu z tej dziedziny, tylko sięgasz
do serialu?

>
> Czytales co pisalem o _? Czy sobie nie zadales trudu? Czy gdzies
> napisalem, ze ma pisac "protected"? Niech i pisze "unprotected", ale
> niech dziala, to wtedy bedzie wsparcie jezyka.

Nadal piszesz o działaniu w konkretnej implementacji tego wzorca w
Java/php.
Czy dla dekoratora też musi być specjalne wsparcie w języku by używać
tego wzorca?

W pythonie masz uproszczenie w postaci @dekorator, czyli java i php
nie wspierają dekoratorów
na poziomie języka? Nie muszą, bo jest to wzorzec, który realizujesz
przy pomocy dostarczonych elementów języka.
Więc protected i _ jest tym samym tak samo jak function i def.

>
>
>
> > Po poznaniu lepiej pythona i kilku innych odmiennych języków zacząłem
> > odróżniać jedno od drugiego.
>
> Gratuluje, ze dopiero wtedy. Masz sie czym chwalic.

Mam, ty jeszcze nie zacząłeś czytając Twoje wypowiedzi oraz porównując
je z pozostałymi dyskutującymi osobami.
Także jako jedyny nie jesteś też w stanie podpisać się pod własnymi
wypowiedziami, czyli siebie samego także nie traktujesz jako
wiarygodne źródło.

Dnia 02-11-2009 o 08:18:59 pakalk <pakalk@gmail.com> napisał(a):


>> > 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.
>
> 1. Nie muszę każdej zmiennej - to jakieś totalne nieporozumienie

Bynajmniej. Chodzi o każdą taką, która mogłaby sypnąć fatal errorem.

> 2. Potem nie trzeba testować jaki wyjątek nam wyskoczył? Ciekawe.

Prawda? Możesz wszystkie wyjątki do kup wyłapać w wyższej warstwie bez  
wnikania w ich rodzaj.

>> 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ć.
>
> Pisze o sytuacji, gdy nie zostanie przechwycony

Tak jest możliwe tylko w PHP bo ma dziurawy system wyjątków. W Pythonie (i  
reszcie normalnych języków) można przechwycić *wszelkie wyjątki*.

>> >> 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!
>
> 5.3
>
> Co pozmieniali?

I ty mówisz że znasz PHP?

> Twórcy UML-a też pewnie jedzą. Czemu o nich nic nie piszesz? ;>

Bo już dostałeś na to odpowiedź. UML nie ma tu nic do rzeczy.

> Metoda klasowa to metoda statyczna.

Oczywiście, że nie. Metoda klasowa to singleton. Czy metoda statyczna może  
być singletonem? Nie. Czy metodę statyczną można przesłaniać? Nie. Czy  
metodę statyczną można wywołać tak jakby wyglądała na klasową? Tak. Czy to  
dowodzi, że to jest konstrukcja obiektowa? Nie.

> Wystarczy spojrzeć na UML

j.w.

> Ale metody statyczne/klasowe sa - co z tego, ze inaczej je nazwiemy?

Singleton to nie jest metoda statyczna. Nawet w Javie singleton nie jest  
metodą statyczną. Mylisz pojęcia.

>> > 1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np. Javie)
>>
>> Nie. Klasa w Pythonie jest obiektem a metoda klasowa jest jej  
>> singletonem.
>
> Mowie o zachowaniu a nie jego realzacji. I sie tak zachowuje.

Właśnie że tak się *nie* zachowuje. Metodę klasową przeciążysz, statyczną  
już nie. Spróbuj jak nie wierzysz.

> Chcesz porozmawiac o kreacjonizmie? ;>

Nie radzę, opiekuję się portalem creationism.org.pl ;)

>> Po pierwsze, klasa może domieszkować wiele traitsów. A nie możesz  
>> dziedziczyć po wielu klasach abstrakcyjnych, tylko po jednej.
>
> Kwestia dziedziczenia wielokrotnego a nie klas abstrakcyjnych. Gdyby
> pozwolic na dziedziczenie wielokrotne w javie, to mozna uzyc
> abstrakcyjnych.

Ale nie można. W PHP też nie można. Więc nie pleć bzdur, że miksiny/traisy  
zachowują się tak jak klasy abstrakcyjne, bo się nie zachowują. Klasy  
abstrakcyjnie nie potrafią nie mają też linearyzacji tak jak traitsy.  
Nawet podałem ci przykład kodu w Scali. Spróbuj napisać coś takiego w  
Javie albo PHP za pomocą interfejsów i klas abstrakcyjnych. Powodzenia!

>> > To jest ich cecha, a nie wada.
>>
>> Cecha, która jest równocześnie ich wadą.
>
> Cecha najnowszego modelu BMW jest to, ze nie jest amfibia. Dla Ciebie
> to moze byc tez wada, dla innych niekoniecznie.

Różnica jest zasadnicza. Ja podałem ci na czym polegają te wady, nawet  
podałem ci przykłady kodu nie do zrealizowania na interfejsach i klasach  
abstrakcyjnych. A co ty pokazałeś? Powtórzę, jeśli nie dotarło.

>> Klasy abstrakcyjne są do bani, bo nie można dziedziczyć po kilku  
>> klasach   abstrakcyjnych. To duże ograniczenie.
>
> To nie jest cecha klas abstrakcyjnych, tylko realizacji przez jezyk. W
> Pythonie mozna chyba?

W Pythonie nie ma przecież klas abstrakcyjnych. :)

-- 
JZ http://blog.zabiello.com

Dnia 02-11-2009 o 08:25:40 pakalk <pakalk@gmail.com> napisał(a):

> Czytales co pisalem o _? Czy sobie nie zadales trudu? Czy gdzies
> napisalem, ze ma pisac "protected"? Niech i pisze "unprotected", ale
> niech dziala, to wtedy bedzie wsparcie jezyka.

Raczej chciałeś napisać "ale niech działa jak w Javie". Python ma tu inną  
filozofię. Nie możesz stawiać zarzutu, że Python nie jest Javą.

Przypomnę, że Ruby i Scala mają takie wsparcie. Zresztą co znaczy spór o  
OOP, coraz ważniejszym paradygmatem jest FP. PHP też nie ma tu czym się  
pochwalić. Scala - ma.

-- 
JZ http://blog.zabiello.com

On Nov 2, 9:37 am, Marek Wywiał <onj...@gmail.com> wrote:
> > Znowu mam ochote zacytowac House'a.
>
> Cytuj, House nazywa idiotami wszystkich, którzy się z nim nie
> zgadzają, nawet jeśli on sam nie ma racji, gdyż widzi tylko swój
> światek.
> Ale on po fakcie przyznaje się, że się mylił. Też docierasz do tego
> etapu?

Chyba Ci sie seriale pomylily.

>
> Z drugiej strony, jeżeli w dyskusji o programowaniu nie jesteś w
> stanie zacytować żadnego autorytetu z tej dziedziny, tylko sięgasz
> do serialu?
>

A Ty kogo cytowales? I co to za tekst w ogole? Ma sens?

>
>
> > Czytales co pisalem o _? Czy sobie nie zadales trudu? Czy gdzies
> > napisalem, ze ma pisac "protected"? Niech i pisze "unprotected", ale
> > niech dziala, to wtedy bedzie wsparcie jezyka.
>
> Nadal piszesz o działaniu w konkretnej implementacji tego wzorca w
> Java/php.
> Czy dla dekoratora też musi być specjalne wsparcie w języku by używać
> tego wzorca?
>
> W pythonie masz uproszczenie w postaci @dekorator, czyli java i php
> nie wspierają dekoratorów
> na poziomie języka? Nie muszą, bo jest to wzorzec, który realizujesz
> przy pomocy dostarczonych elementów języka.
> Więc protected i _ jest tym samym tak samo jak function i def.

Jednak jestes idiota. _ nie realizuje nic i zadnym dekoratorem nie
jest.

>
>
>
> > > Po poznaniu lepiej pythona i kilku innych odmiennych języków zacząłem
> > > odróżniać jedno od drugiego.
>
> > Gratuluje, ze dopiero wtedy. Masz sie czym chwalic.
>
> Mam, ty jeszcze nie zacząłeś czytając Twoje wypowiedzi oraz porównując
> je z pozostałymi dyskutującymi osobami.
> Także jako jedyny nie jesteś też w stanie podpisać się pod własnymi
> wypowiedziami, czyli siebie samego także nie traktujesz jako
> wiarygodne źródło.

Jw.

On Nov 2, 9:51 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> > 2. Potem nie trzeba testować jaki wyjątek nam wyskoczył? Ciekawe.
>
> Prawda? Możesz wszystkie wyjątki do kup wyłapać w wyższej warstwie bez  
> wnikania w ich rodzaj.

I ciekawe jak grupowo obslugujesz kilka roznych wyjatkow. Bardzo
ciekawe. Chyba zapisujac to tylko do loga.

>
> > Pisze o sytuacji, gdy nie zostanie przechwycony
>
> Tak jest możliwe tylko w PHP bo ma dziurawy system wyjątków. W Pythonie (i  
> reszcie normalnych języków) można przechwycić *wszelkie wyjątki*.

Mozna ale nie trzeba. Ify tez mozna wszedzie wsadzic.

>
> I ty mówisz że znasz PHP?

Tak, znam.

No powiedz mi co pozmieniali? Tzn. o co konkretnie Ci chodzi.

>
> > Twórcy UML-a też pewnie jedzą. Czemu o nich nic nie piszesz? ;>
>
> Bo już dostałeś na to odpowiedź. UML nie ma tu nic do rzeczy.

Jasne. Model obiektowy i jego wlasnosci ustalaja bywalcy tej grupy
dyskusyjnej.


>
> > Wystarczy spojrzeć na UML
>
> j.w.

j.w.

>
> > Ale metody statyczne/klasowe sa - co z tego, ze inaczej je nazwiemy?
>
> Singleton to nie jest metoda statyczna. Nawet w Javie singleton nie jest  
> metodą statyczną. Mylisz pojęcia.

Jakie znaczenie ma sposob realizacji funkcji metody statycznej?

>
> >> > 1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np. Javie)
>
> >> Nie. Klasa w Pythonie jest obiektem a metoda klasowa jest jej  
> >> singletonem.
>
> > Mowie o zachowaniu a nie jego realzacji. I sie tak zachowuje.
>
> Właśnie że tak się *nie* zachowuje. Metodę klasową przeciążysz, statyczną  
> już nie. Spróbuj jak nie wierzysz.

W javie nie ma np. dzidziczenia wielokrotnego, co nie znaczy, ze nie
ma dziedziczenia.
W PHP przeciazysz metody statyczne. Nie wierzysz? Sprawdz.

Tak wiem.. zaraz mi napiszesz, ze lipne to - ale to nie jest cecha
metod statycznych. One wykonywane sa w kontekscie klasy - znaczy sa
klasowe. Tak sie nazywaja w UML, a on bazuje na Javie i zapewniam -
metoda klasowa zamodelowana w UML bedzie zrealizowana jako statyczna w
Javie.

Jesli chodzi o realizacje (w pythonie, jak rozumiem, klasa to de facto
instancja klasy klasy, wiec odpalenie metody klasowej odpala ja w
kontekscie obiektu klasy - jesli nie to musze doczytac) to nie jest to
wazne na poziomie abstrakcji. Klopot w tym, ze kazdy jezyk chce byc
trendy i wprowadza udziwnione nazwy (vide Scala), uzywa nazw
alternatywnych (vide: funkcja, subroutine, def), modyfikuje wlasnosci
znanych juz elementow programowania albo uzywa nazw w innych
kontekscie (@staticmethod). Z tego powstaja potem spory jak ten - bo
to co sie nazywa tak w pythonie inaczej nazywa sie w javie a dziala
tez nieco inaczej, bo sam jezyk jest inny. Ale to jest raczej szczegol
(albo ogol?) implementacyjny, koncepcyjny dot. konkretnego jezyka i
jego mozliwosci a nie tego co robi metoda statyczna. Podazajac wstecz,
w historii, mozemy mowic o tym, ze zmienne statyczne to jeszcze cos
innego niz w javie...

>
> > Chcesz porozmawiac o kreacjonizmie? ;>
>
> Nie radzę, opiekuję się portalem creationism.org.pl ;)

..i biblia.apologetyka.com też, z tego co pamiętam ;)

Dlatego wlasnie to napisalem, odnosnie opierania sie na wierze ;)


>
> >> Klasy abstrakcyjne są do bani, bo nie można dziedziczyć po kilku  
> >> klasach   abstrakcyjnych. To duże ograniczenie.
>
> > To nie jest cecha klas abstrakcyjnych, tylko realizacji przez jezyk. W
> > Pythonie mozna chyba?
>
> W Pythonie nie ma przecież klas abstrakcyjnych. :)
>

Tak? A takie ABC to co jest?

Gdybym byl zlosliwy, tobym Cie sparafrazowal i napisal: "I Ty sie
znasz na pythonie?", ale nie napisze :P

On Nov 2, 10:06 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> Dnia 02-11-2009 o 08:25:40 pakalk <pak...@gmail.com> napisał(a):
>
> > Czytales co pisalem o _? Czy sobie nie zadales trudu? Czy gdzies
> > napisalem, ze ma pisac "protected"? Niech i pisze "unprotected", ale
> > niech dziala, to wtedy bedzie wsparcie jezyka.
>
> Raczej chciałeś napisać "ale niech działa jak w Javie". Python ma tu inną  
> filozofię. Nie możesz stawiać zarzutu, że Python nie jest Javą.

Nie stawiam.

Tylko, ze tu nic nie dziala, bo tego nie ma. To umowa miedzy
programistami, ze nie ruszaja tego co ma _ z przodu. I dobrze, jak to
dziala, to niech tak bedzie. Ale rownie dobrze mozna sie umowic, ze
nie ruszamy niczego co zaczyna sie na A. Albo - tak jak w
borlandowskim C++ - wszystkie klasy zaczynac od T. Albo od C, jak w
ogolnej konwencji C++. Albo mozemy stosowac notacje wegierska. Tylko,
ze guzik to ma do wsparcia ze strony jezyka, poki kompilator/
interpreter nie sprawdza, czy ktos nie uzywa _funkcji() jak
publicznej.

>
> Przypomnę, że Ruby i Scala mają takie wsparcie.

Spoko. C++, Java, PHP tez. Tylko co to ma do pythona? ;>

> Zresztą co znaczy spór o  
> OOP, coraz ważniejszym paradygmatem jest FP. PHP też nie ma tu czym się  
> pochwalić. Scala - ma.

Nie powiedzialbym, zeby to bylo jakos strasznie dobre. Struktury i
operacje na nich musza zostac domena OOP. Programowanie funkcyjne (a
raczej proceduralne) moze byc przydatne jako zbior narzedzi
operujacych na danych roznych typow. Dlatego dobrym rozwiazaniem jest
len() zamiast .length() w pythonie - bo tak naprawde, jak w zyciu,
sposob zliczenia elementow nie zalezy od nich samych, a moze sie
zmienic odgornie.

Wazne jednak sa dobre namespace'y albo moduly albo pakiety, albo jak
kto tam to zwal. Wazne, zeby funkcje byly pogrupowane, a kod
uporzadkowany - wtedy jest ok. W PHP rzeczywiscie sobie tego teraz nie
wyobrazam. Mimo NS - bo one jakies zje*ane mi sie wydaja przez te \\\\\
\\\\\\\\\\\\ backslashe.

On 02.11.2009, pakalk <pakalk@gmail.com> wroted:

>> > 2. Potem nie trzeba testować jaki wyjątek nam wyskoczył?
>> > Ciekawe.
>>
>> Prawda? Możesz wszystkie wyjątki do kup wyłapać w wyższej
>> warstwie bez   wnikania w ich rodzaj.
>
> I ciekawe jak grupowo obslugujesz kilka roznych wyjatkow. Bardzo
> ciekawe. Chyba zapisujac to tylko do loga.

Taaak. Coraz bardziej widać, ile masz realnie wspólnego 
z programowaniem. Nigdy nie pisałeś czegoś, w czym cały 
duży blok kodu odpowiada za, z punktu widzenia funkcji
programu, jedną operację? Wszystko co musisz w takim 
przypadku zrobić, to przechwycić _dowolny_ wyjątek i np.
a) zignorować go i przejść do radzenia sobie z sytuacją
wystąpienia błędu, albo b) wyświetlić userowi komunikat 
"soraski wielkie gościu, ale to się nie udało -- jak cię 
interesują bzdurki dla technicznych, to se kliknij tu, 
a zobaczysz traceback". Możesz mi wyjaśnić, dlaczego 
niezbędne miałoby być w takiej sytuacji zapisywanie 
czegokolwiek do loga? Albo różnicowanie zachowania 
programu w zależności od tego jaki wyjątek się pojawił?

Możesz oczywiście zacytować House'a, albo zignorować 
pytanie, jeśli to ci poprawi humor -- w tym przynajmniej 
jesteś dobry.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On Nov 2, 6:32 pm, Grzegorz Staniak <gstan...@wp.pl> wrote:
> On 02.11.2009, pakalk <pak...@gmail.com> wroted:
>
> >> > 2. Potem nie trzeba testować jaki wyjątek nam wyskoczył?
> >> > Ciekawe.
>
> >> Prawda? Możesz wszystkie wyjątki do kup wyłapać w wyższej
> >> warstwie bez   wnikania w ich rodzaj.
>
> > I ciekawe jak grupowo obslugujesz kilka roznych wyjatkow. Bardzo
> > ciekawe. Chyba zapisujac to tylko do loga.
>
> Taaak. Coraz bardziej widać, ile masz realnie wspólnego
> z programowaniem. Nigdy nie pisałeś czegoś, w czym cały
> duży blok kodu odpowiada za, z punktu widzenia funkcji
> programu, jedną operację? Wszystko co musisz w takim
> przypadku zrobić, to przechwycić _dowolny_ wyjątek i np.
> a) zignorować go i przejść do radzenia sobie z sytuacją
> wystąpienia błędu, albo

Ignorowanie bledow jest super sposobem na radzenie sobie z nimi.

> b) wyświetlić userowi komunikat
> "soraski wielkie gościu, ale to się nie udało -- jak cię
> interesują bzdurki dla technicznych, to se kliknij tu,

O tak - Ty masz duzo wspolnego szczegolnie z bezpieczenstwem, jak
chcesz userowi backtrace wystawic...

> a zobaczysz traceback". Możesz mi wyjaśnić, dlaczego
> niezbędne miałoby być w takiej sytuacji zapisywanie
> czegokolwiek do loga?

Zapisywanie bledow do loga, tak czy owak, powinno miec miejsce. Zeby
wiedziec, ze wystapily.

> Albo różnicowanie zachowania
> programu w zależności od tego jaki wyjątek się pojawił?

Dlatego, ze na rozne bledy roznie nalezy reagowac. Chyba, ze chcesz
wlasnie blad zignorowac, co rozwiazaniem problemu nie jest. (Chyba, ze
wiesz, ze blad moze wystapic i masz to w d).

Ok, juz nie ciagne tematu z obsluga wyjatkow. Tak - jest prosciej z
wyjatkami.

On 02.11.2009, pakalk <pakalk@gmail.com> wroted:

>> > I ciekawe jak grupowo obslugujesz kilka roznych wyjatkow. Bardzo
>> > ciekawe. Chyba zapisujac to tylko do loga.
>>
>> Taaak. Coraz bardziej widać, ile masz realnie wspólnego z
>> programowaniem. Nigdy nie pisałeś czegoś, w czym cały duży
>> blok kodu odpowiada za, z punktu widzenia funkcji programu, jedną
>> operację? Wszystko co musisz w takim przypadku zrobić, to
>> przechwycić _dowolny_ wyjątek i np. a) zignorować go i przejść
>> do radzenia sobie z sytuacją wystąpienia błędu, albo
>
> Ignorowanie bledow jest super sposobem na radzenie sobie z nimi.

Przejście do kodu napisanego na wypadek wystąpienia wyjątku 
jest według ciebie gorsze od rzucenia fatal errora? Może już 
jednak za długo używasz tego PHP.

>> b) wyświetlić userowi komunikat "soraski wielkie gościu, ale to
>> się nie udało -- jak cię interesują bzdurki dla technicznych,
>> to se kliknij tu,
>
> O tak - Ty masz duzo wspolnego szczegolnie z bezpieczenstwem, jak
> chcesz userowi backtrace wystawic...

Się odezwał praktyk. Ile robiłeś wdrożeń dla działów IT w firmach
zatrudniających powyżej 1000 osób?

>> a zobaczysz traceback". Możesz mi wyjaśnić, dlaczego niezbędne
>> miałoby być w takiej sytuacji zapisywanie czegokolwiek do loga?
>
> Zapisywanie bledow do loga, tak czy owak, powinno miec miejsce. 
> Zeby wiedziec, ze wystapily.

Ale nie musi mieć miejsca, jeśli nie chcesz. To tylko w pehapie
obsługa błędów oznacza grzebanie po logach.

>> Albo różnicowanie zachowania programu w zależności od tego jaki
>> wyjątek się pojawił?
>
> Dlatego, ze na rozne bledy roznie nalezy reagowac. 

Nie, nie "należy". Jeśli błąd z punktu widzenia funkcji programu
dotyczy jednej operacji, wystarczy informacja, że operacja się 
nie udała. Dlaczego się nie udała jest ważne dla programisty, 
a ten ma traceback do dyspozycji.

> Chyba, ze chcesz wlasnie blad zignorowac, co rozwiazaniem problemu
> nie jest. 

Tobie się myli błąd programisty z sytuacją wyjątku w programie. 
Wyjątek może być oprogramowany na śmierć i nie powodować
najmniejszych niepożądanych efektów w pracy programu. Wyjątek
nie jest "problemem", jest normą.

> (Chyba, ze wiesz, ze blad moze wystapic i masz to w d).

Łomatko, po namyśle zaczynasz łapać. Gratulacje.

GS
-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

On 02.11.2009, pakalk <pakalk@gmail.com> wrote:
>> Taaak. Coraz bardziej widać, ile masz realnie wspólnego
>> z programowaniem. Nigdy nie pisałeś czegoś, w czym cały
>> duży blok kodu odpowiada za, z punktu widzenia funkcji
>> programu, jedną operację? Wszystko co musisz w takim
>> przypadku zrobić, to przechwycić _dowolny_ wyjątek i np.
>> a) zignorować go i przejść do radzenia sobie z sytuacją
>> wystąpienia błędu, albo
> Ignorowanie bledow jest super sposobem na radzenie sobie z nimi.
Ojjjj.... Przykład: błąd połączenia z serwerem (jakikolwiek) można
obsłużyć po przechwyceniu wyjątku, np. przełączając się na
slave/backup/whateva i ponawiając request. Nie ma wtedy dla nas znaczenia
co to jest za błąd (host nie odpowiada, zrywa połączenie itp.), informację
szczegółową można wrzucić do logów, aplikacja ma jednak działać dalej.
Ma to ogromne znaczenie w przypadku systemów bezobsługowych.
Bez wyjątków trzeba sprawdzać każde wywołanie jakiejkolwiek funkcji
gadającej z serwerem, czy przypadkiem nie wystąpił jakiś błąd.


Pozdrawiam
Beorn

-- 
Daniel 'Beorn' Mróz <beorn@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+                           ]

On 2 Lis, 17:55, pakalk <pak...@gmail.com> wrote:
> On Nov 2, 10:06 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> > Dnia 02-11-2009 o 08:25:40 pakalk <pak...@gmail.com> napisał(a):
>
> > > Czytales co pisalem o _? Czy sobie nie zadales trudu? Czy gdzies
> > > napisalem, ze ma pisac "protected"? Niech i pisze "unprotected", ale
> > > niech dziala, to wtedy bedzie wsparcie jezyka.
>
> > Raczej chciałeś napisać "ale niech działa jak w Javie". Python ma tu inną  
> > filozofię. Nie możesz stawiać zarzutu, że Python nie jest Javą.
>
> Nie stawiam.
>
> Tylko, ze tu nic nie dziala, bo tego nie ma. To umowa miedzy
> programistami, ze nie ruszaja tego co ma _ z przodu. I dobrze, jak to
> dziala, to niech tak bedzie.

Jak już uprzednio napisano w Java/PHP też możesz odczytać/zmienić
wartości private/protected i kompilator/interpreter
nawet się nie zająknie. W pythonie zamiast więc ludziom tłumaczyć, że
tego się nie da, a kiedyś im powiedzieć, że jednak się da,
od razu dostajesz informację, że się da jak potrzebujesz. Ale masz
oznaczone, że jest używane do celów prywatnych i znasz tego
konsekwencje.
Tak samo jak w Java/PHP.

Dnia 02-11-2009 o 16:55:52 pakalk <pakalk@gmail.com> napisał(a):

>> Raczej chciałeś napisać "ale niech działa jak w Javie". Python ma tu  
>> inną filozofię. Nie możesz stawiać zarzutu, że Python nie jest Javą.
>
> Nie stawiam.
[...]
> Tylko, ze guzik to ma do wsparcia ze strony jezyka, poki kompilator/
> interpreter nie sprawdza, czy ktos nie uzywa _funkcji() jak
> publicznej.

A po co ma sprawdzać, skoro to oczywiste dla każdego kto zna Pythona? Nie  
wiem coś tak się uczepił tego _ a nie wspominasz nic o maglingu do __. Tam  
jakakolwiek pomyłka jest raczej wykluczona nawet przez kompletnego  
nowicjusza.

> Programowanie funkcyjne (a raczej proceduralne) moze byc przydatne jako 
> zbior narzedzi operujacych na danych roznych typow.

Programowanie funkcyjne nie ma nic wspólnego z programowaniem  
proceduralnym. Doczytałbyś sobie trochę o FP zamiast takie bzdury pisać.

-- 
JZ http://blog.zabiello.com

Dnia 02-11-2009 o 16:47:52 pakalk <pakalk@gmail.com> napisał(a):

>> Prawda? Możesz wszystkie wyjątki do kup wyłapać w wyższej warstwie bez  
>> wnikania w ich rodzaj.
>
> I ciekawe jak grupowo obslugujesz kilka roznych wyjatkow. Bardzo
> ciekawe. Chyba zapisujac to tylko do loga.

Dobry dowcip. Przecież nawet w PHP wyłapiesz wiele wyjątków jednym  
blokiem. Problem tylko w tym, że pehap wyrzuca też błędy, które nie są  
wyjątkami i nie są do wychwycenia w żaden sposób. Więc z konieczności  
musisz grzebać się w logach aby po fakcie coś tam znaleźć.

>> I ty mówisz że znasz PHP?
>
> Tak, znam.
> No powiedz mi co pozmieniali? Tzn. o co konkretnie Ci chodzi.

Skoro znasz, to powinieneś coś wiedzieć. :P

>> > Ale metody statyczne/klasowe sa - co z tego, ze inaczej je nazwiemy?
>>
>> Singleton to nie jest metoda statyczna. Nawet w Javie singleton nie  
>> jest  metodą statyczną. Mylisz pojęcia.
>
> Jakie znaczenie ma sposob realizacji funkcji metody statycznej?

No bo czym jest metoda statyczna skoro może ona działać dowolnie? To wtedy  
staje się puste słowo bez treści. :P

>> >> > 1. Metoda klasowa (np. w pythonie) == metoda statyczna (w np.   
>> Javie)
>>
>> >> Nie. Klasa w Pythonie jest obiektem a metoda klasowa jest jej >>  
>> singletonem.
>>
>>> Mowie o zachowaniu a nie jego realzacji. I sie tak zachowuje.

Właśnie w tym problem że metoda statyczna Javy nie zachowuje się tak, jak  
metoda klasowa Pythona. Metodę statyczną Javy możesz tylko przesłonić. Nie  
możesz jej jednak przeciążyć.

> W javie nie ma np. dzidziczenia wielokrotnego, co nie znaczy, ze nie
> ma dziedziczenia.

Nikt nie twierdzi że w Javie nie ma żadnego dziedziczenia. Po co o tym  
piszezz?

> W PHP przeciazysz metody statyczne. Nie wierzysz? Sprawdz.

W PHP - tak, w Javie - nie.

> Tak wiem.. zaraz mi napiszesz, ze lipne to - ale to nie jest cecha
> metod statycznych. One wykonywane sa w kontekscie klasy - znaczy sa
> klasowe. Tak sie nazywaja w UML, a on bazuje na Javie i zapewniam -
> metoda klasowa zamodelowana w UML bedzie zrealizowana jako statyczna w
> Javie.

To się źle nazywa. Mało mnie obchodzi UML. Metody statycznej Javy nie  
przeciążysz, bo się nie da. Można ją tylko przesłonić.

class Foo {
   public static void classMethod() {
     System.out.println(“classMethod() in Foo”);
     }
   public void instanceMethod() {
     System.out.println(“instanceMethod() in Foo”);
   }
}

class Bar extends Foo {
   public static void classMethod() {
     System.out.println(“classMethod() in Bar”);
     }
   public void instanceMethod() {
     System.out.println(“instanceMethod() in Bar”);
   }
}

class Test {
   public static void main(String[] args) {
     Foo f = new Bar();
     f.instanceMethod();
     f.classMethod();
   }
}

wynik:

instanceMethod() in Bar
classMethod() in Foo

> Klopot w tym, ze kazdy jezyk chce byc trendy i wprowadzaudziwnione nazwy  
> (vide Scala),

Jakie znowu dziwne nazwy? Przecież wykazałem ci błąd twierdzenia, że  
traitsy to funkcjonalnie klasy abstrakcyjne. Klasy abstrakcyjne nie mogę  
być wielokrotnie dziedziczone ani domieszkowane. Klasy abstrakcyjne nie  
mają linearyzacji.

Scala jako język jest dosyć minimalistyczna. Nawet operatorów nie ma, bo  
po co komu takie ograniczenia? ;)

> ..i biblia.apologetyka.com też, z tego co pamiętam ;)
>
> Dlatego wlasnie to napisalem, odnosnie opierania sie na wierze ;)

A co tu wiara ma do rzeczy? Przecież to tylko rozbudowana wyszukiwarka  
tekstu Biblii. To nie wiary potrzeba ale minimalnej inteligencji aby z jej  
skorzystać. Zrobiłem sobie też wyszukiwarkę polskich przekładów Koranu. To  
też wymaga wiary, tym razem w Koran? lol

> Tak? A takie ABC to co jest?

Nie śledzę wszystkich zmian w Pythonie (nie używam go na codzień). Fakt,  
że to doszło dopiero od wersji 2.6.

-- 
JZ http://blog.zabiello.com

On Nov 2, 11:06 pm, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
> Dnia 02-11-2009 o 16:55:52 pakalk <pak...@gmail.com> napisał(a):
>
>
>
> >> Raczej chciałeś napisać "ale niech działa jak w Javie". Python ma tu  
> >> inną filozofię. Nie możesz stawiać zarzutu, że Python nie jest Javą.
>
> > Nie stawiam.
> [...]
> > Tylko, ze guzik to ma do wsparcia ze strony jezyka, poki kompilator/
> > interpreter nie sprawdza, czy ktos nie uzywa _funkcji() jak
> > publicznej.
>
> A po co ma sprawdzać, skoro to oczywiste dla każdego kto zna Pythona? Nie  
> wiem coś tak się uczepił tego _ a nie wspominasz nic o maglingu do __. Tam  
> jakakolwiek pomyłka jest raczej wykluczona nawet przez kompletnego  
> nowicjusza.

Bo __ jest obslugiwany przez jezyk, _ nie. Ciezko to pojac, ze
konwencja to nie wsparcie jezyka?

>
> > Programowanie funkcyjne (a raczej proceduralne) moze byc przydatne jako
> > zbior narzedzi operujacych na danych roznych typow.
>
> Programowanie funkcyjne nie ma nic wspólnego z programowaniem  
> proceduralnym. Doczytałbyś sobie trochę o FP zamiast takie bzdury pisać.
>

Wiem. Sadzilem, ze chodzi Ci o proceduralne wlasnie.

On Nov 3, 2:19 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> Skoro znasz, to powinieneś coś wiedzieć. :P

No to wlasnie pytam, co sie znaczaco zmienilo oprocz LSB i paru
magicznych metod?

>
> No bo czym jest metoda statyczna skoro może ona działać dowolnie? To wtedy  
> staje się puste słowo bez treści. :P

Slowo to slowo, a nie cialo. Pomysl, idea.

>
> > W javie nie ma np. dzidziczenia wielokrotnego, co nie znaczy, ze nie
> > ma dziedziczenia.
>
> Nikt nie twierdzi że w Javie nie ma żadnego dziedziczenia. Po co o tym  
> piszezz?

Piszesz o metodach klasowych, jakby ich nie bylo, bo dzialaja inaczej.

>
> > W PHP przeciazysz metody statyczne. Nie wierzysz? Sprawdz.
>
> W PHP - tak, w Javie - nie.

No i ok. W zwiazku z tym juz metody statyczne z PHP sa jak klasowe z
Pythona, czy nie? A moze rowniez te z javy to jedno i to samo, ale
zrealizowane w inny sposob, z innym spektrum mozliwosci, uwarunkowanym
przez jezyk?

>
> > Tak wiem.. zaraz mi napiszesz, ze lipne to - ale to nie jest cecha
> > metod statycznych. One wykonywane sa w kontekscie klasy - znaczy sa
> > klasowe. Tak sie nazywaja w UML, a on bazuje na Javie i zapewniam -
> > metoda klasowa zamodelowana w UML bedzie zrealizowana jako statyczna w
> > Javie.
>
> To się źle nazywa. Mało mnie obchodzi UML. Metody statycznej Javy nie  
> przeciążysz, bo się nie da. Można ją tylko przesłonić.
>
> (...)
>
> wynik:
>
> instanceMethod() in Bar
> classMethod() in Foo

Może dlatego, że nie została zaprojektowana do odpalania na
instancjach, tylko w kontekscie klasy, a jesli jest odpalona na
instancji, to celowo trzyma sie kontekstu oryginalnej klasy, zeby moc
obsluzyc dane w taki sposob w jaki one sa zapisane w ramach tejze
klasy? Nie wiem. Mozliwosci tych metod sa inne niz w Pythonie, chocby
dlatego, ze rozne sa podejscia do jezyka, ale to nie znaczy, ze nie
moga realizowac tych samych zadan (ja raczej rzadko mam potrzebe
korzystania z metod statycznych w nizszych instancjach - jak chce cos
przeciazac, to metody instancyjne - wtedy i polimorfizm ma sens, bo
jak zapisales Foo x = new Bar() operuje na instancjach, a nie na
klasach).

>
> > Klopot w tym, ze kazdy jezyk chce byc trendy i wprowadzaudziwnione nazwy  
> > (vide Scala),
>
> Jakie znowu dziwne nazwy?

traits

> Przecież wykazałem ci błąd twierdzenia, że  
> traitsy to funkcjonalnie klasy abstrakcyjne. Klasy abstrakcyjne nie mogę  
> być wielokrotnie dziedziczone ani domieszkowane. Klasy abstrakcyjne nie  
> mają linearyzacji.

Ok

>
> Scala jako język jest dosyć minimalistyczna. Nawet operatorów nie ma, bo  
> po co komu takie ograniczenia? ;)

Zalezy jak na to patrzec... Mozna powiedziec, ze operatorow tam tyle
co metod ;)

>
> > ..i biblia.apologetyka.com też, z tego co pamiętam ;)
>
> > Dlatego wlasnie to napisalem, odnosnie opierania sie na wierze ;)
>
> A co tu wiara ma do rzeczy? Przecież to tylko rozbudowana wyszukiwarka  
> tekstu Biblii. To nie wiary potrzeba ale minimalnej inteligencji aby z jej  
> skorzystać. Zrobiłem sobie też wyszukiwarkę polskich przekładów Koranu. To  
> też wymaga wiary, tym razem w Koran? lol

Nie, ale kreacjonizm juz wymaga. O biblia.apologetyka.com tylko
wspomnialem.

On Nov 3, 8:11 am, pakalk <pak...@gmail.com> wrote:
> On Nov 3, 2:19 am, "Jaroslaw Zabiello" <use...@onet.eu> wrote:
>
> > > W PHP przeciazysz metody statyczne. Nie wierzysz? Sprawdz.
>
> > W PHP - tak, w Javie - nie.
>
> No i ok. W zwiazku z tym juz metody statyczne z PHP sa jak klasowe z
> Pythona, czy nie? A moze rowniez te z javy to jedno i to samo, ale
> zrealizowane w inny sposob, z innym spektrum mozliwosci, uwarunkowanym
> przez jezyk?
>
> > > Tak wiem.. zaraz mi napiszesz, ze lipne to - ale to nie jest cecha
> > > metod statycznych. One wykonywane sa w kontekscie klasy - znaczy sa
> > > klasowe. Tak sie nazywaja w UML, a on bazuje na Javie i zapewniam -
> > > metoda klasowa zamodelowana w UML bedzie zrealizowana jako statyczna w
> > > Javie.
>
> > To się źle nazywa. Mało mnie obchodzi UML. Metody statycznej Javy nie  
> > przeciążysz, bo się nie da. Można ją tylko przesłonić.
>
> > (...)
>
> > wynik:
>
> > instanceMethod() in Bar
> > classMethod() in Foo
>
> Może dlatego, że nie została zaprojektowana do odpalania na
> instancjach, tylko w kontekscie klasy, a jesli jest odpalona na
> instancji, to celowo trzyma sie kontekstu oryginalnej klasy, zeby moc
> obsluzyc dane w taki sposob w jaki one sa zapisane w ramach tejze
> klasy? Nie wiem. Mozliwosci tych metod sa inne niz w Pythonie, chocby
> dlatego, ze rozne sa podejscia do jezyka, ale to nie znaczy, ze nie
> moga realizowac tych samych zadan (ja raczej rzadko mam potrzebe
> korzystania z metod statycznych w nizszych instancjach - jak chce cos
> przeciazac, to metody instancyjne - wtedy i polimorfizm ma sens, bo
> jak zapisales Foo x = new Bar() operuje na instancjach, a nie na
> klasach).

Ja ma tylko pytanie. Czy możecie w imię starej, umęczonej Javy
przestać pisać takie pierdoły? Co drugą linijkę mylicie podstawowe
pojęcia (chociażby przeciążanie [overloading, ad-hoc polymorphism ] z
przesłanianiem [overriding, inheritance]). A później jeszcze
dorabiacie filozofię i debatujecie nad przykładem, który pokazuję
jedynie, że kompilator umioe poprawnie zamienić f.x() na declared_type
(f).x() - bo wiązanie metod jest statyczne, a metody "static" są nie
wirtualne (można poznać bo braku super) i broń boże nie mają jakiegoś
mistycznego kontekstu związanego z klasą (co można poznać po braku
this).

Więc proszę was, jak już trolujecie na tej grupie, to przynajmniej o
czymś o czym macie chociaż jakiegokwiek pojęcie. Ja z chęcią mogę
posłuchać o kreacjonizmie  - przynajmniej może czegoś się dowiem.

On Tue, 03 Nov 2009 07:11:57 -0000, pakalk <pakalk@gmail.com> wrote:

>> Skoro znasz, to powinieneś coś wiedzieć. :P
>
> No to wlasnie pytam, co sie znaczaco zmienilo oprocz LSB i paru
> magicznych metod?

Hint: self, hint: statyczne metody abstrakcyjne, itp. Oczywiście nadal ten  
model jest do dupy bo klasa nie jest obiektem, nie może być przekazywana  
jako parametr. Np. takie operowanie metodami klasowymi jak w Ruby jest  
kompletnie nieosiągalne w PHP.

>> No bo czym jest metoda statyczna skoro może ona działać dowolnie? To  
>> wtedy staje się puste słowo bez treści. :P
>
> Slowo to slowo, a nie cialo.

cuagccc348cq8gc to cuagccc348cq8gc a nie ciało :P

> Pomysl, idea.

Aby mówić o idei musisz pojęcie zdefiniować i upewnić się czy twoje  
rozumienie koresponduje z definicją kogoś innego. Inaczej masz ekwiwokację  
i bezproduktywny spór o słowa.

Aby było ideą musisz je zdefiniować i uzgodnić że zgadzamy się na taką  
definicję.

> Piszesz o metodach klasowych, jakby ich nie bylo, bo dzialaja inaczej.

Spór o słowa.

>> Jakie znowu dziwne nazwy?
>
> traits

A jaką nazwę byś chciał? Ani to klasa ani interfejs.

>> Scala jako język jest dosyć minimalistyczna. Nawet operatorów nie ma,  
>> bo  po co komu takie ograniczenia? ;)
>
> Zalezy jak na to patrzec... Mozna powiedziec, ze operatorow tam tyle
> co metod ;)

I b. dobrze. Bo dzięki temu nie trzeba zmieniać implementacji języka aby  
dodać coś nowego. Vide: actors.

> Nie, ale kreacjonizm juz wymaga.

Ewolucjonizm wymaga jeszcze większej wiary. :P

-- 
JZ http://blog.zabiello.com

On Tue, 03 Nov 2009 10:57:56 -0000, Łukasz Rekucki <lrekucki@gmail.com>  
wrote:

> Więc proszę was, jak już trolujecie na tej grupie, to przynajmniej o
> czymś o czym macie chociaż jakiegokwiek pojęcie. Ja z chęcią mogę
> posłuchać o kreacjonizmie  - przynajmniej może czegoś się dowiem.

Poglądy polskich kreacjonistów znajdziesz na http://creationism.org.pl.

PS, ale to chyba nie ta grupa na taki temat...

-- 
JZ http://blog.zabiello.com

On 3 Lis, 11:57, Łukasz Rekucki <lreku...@gmail.com> wrote:
>
> Ja ma tylko pytanie. Czy możecie w imię starej, umęczonej Javy
> przestać pisać takie pierdoły? Co drugą linijkę mylicie podstawowe
> pojęcia (chociażby przeciążanie [overloading, ad-hoc polymorphism ] z
> przesłanianiem [overriding, inheritance]).

Ok. Oczywiscie wyzej chodzilo o overwriting a nie overloading.

> A później jeszcze
> dorabiacie filozofię i debatujecie nad przykładem, który pokazuję
> jedynie, że kompilator umioe poprawnie zamienić f.x() na declared_type
> (f).x() - bo wiązanie metod jest statyczne, a metody "static" są nie
> wirtualne (można poznać bo braku super) i broń boże nie mają jakiegoś
> mistycznego kontekstu związanego z klasą (co można poznać po braku
> this).

Ktore odnosi sie do instancji, wiec ciezko, aby mialy miec, kiedy nie
ma instancji.