🚀 go-pugleaf

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