🚀 go-pugleaf

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.