Python Opcje

[Jabol]

Swoją drogą to znowu dajesz nieadekwatny przykład, bo Java daje możliwość dzielenia przez zero (wyrzuca wyjątek Infinity, czy tam daje integerowi wielkość infinity, czy jakoś tak?). To oczywiście taki żarcik tylko i nie zarzucajcie mi, że odpowiadam nieadekwatnie.

A tak swoją drogą to Smalltalk też był inspirowany Lispem (wg Wikipedii), więc nie dziwota, że struktury danych unifikują się w nim z językiem i jego implementacją. Co do JS to nie wiem więc się nie wypowiadam. I uważam, że niepoprawnie zarzucasz mi przesadzanie, jeżeli chodzi o możliwości rozszerzania Pythona w nim samym. Jeżeli w PHP da się zrobić przestrzenie nazw w taki sposób, że dla korzystających z tego mechanizmu będzie to transparentne, to znaczy, że istnieje taka możliwość i przestrzenie nazw w PHP istnieją. Ja nie widzę problemu w takiej implementacji. Bardziej patrze na funkcjonalność. Ale w sumie nie zajmuje się tym profesjonalnie, może moje podejście nie jest uznawane...

Z tym sprowadzaniem czegośtam do czegośtam to też nie całkiem się zgodzę. Przeszkadza Ci, że coś sie implementuje na poziomie podłoża aplikacji, a nie przeszkadza Ci, że o poziom wyżej (albo raczej niżej) zostało by to zaimplementowane w ten sam sposób. Asembler(czyli de facto kod maszynowy) to język o podejściu imperatywnym, bo nie ma jak na razie maszyn, które umiałyby myśleć. Dlatego wszystkie techniki sprowadzają się w końcu do jednego. Chodzi mi o to, że nie jest to dla programisty na określonym poziomie istotne na którym poziomie poniżej jego kod zostaje zinterpretowany oraz/lub zastosowany, skoro i tak jest to poziom poza jego domeną... (czyli inaczej mówiąc nie jest ważne, czy interfejs to nakładka, czy implementacja, bo i tak działa tak samo w obu przypadkach - zakładając, że rozszerzony język jest środowsikiem, a nie częścią aplikacji docelowej).

Też jestem za tym, abyśmy się nie kłócili:). Dlatego może dodam podstawę mojego myślenia. Interfejs to dla mnie nie część języka, a raczej technika programowania. Wg takiego myślenia można zrobić wsparcie dla interfejsów nawet w asemblerze i C ('struct PyTypeObject' w Pythonie to też np. swoisty interfejs, który poszczególne typy implementują). Jako części języka python tego rzeczywiście nie ma.

Jak już zacząłem temat rozszerzania Pythona w nim samym, to dodam może jeszcze parę słów o tym.
1. Istnieją metaklasy. O tym sobie szukajcie jak sami chcecie, ja nie mam o tym zielonego pojęcia, oprócz tego, że "jest to tak magiczne, że prawdopodbnie nigdy mi się nie przyda" (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) i pozwalają zrobić praktycznie wszystko, rozszerzać Pythona bezgranicznie, pozostawiając go wciąż "pythonowym".
2. Klasy nowego typu. To już rzecz skolei bardzo użyteczna dla każdego Kiedyś klasa w Pythonie była klasą - typem danych. Klasa nowego typu jest typem - częścią języka. Otwiera to jak się domyślacie bardzo wielkie możliwości (teraz się zastanawiam jak wielkie muszą być możliwości metaklas:?). To tyle ode mnie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . Reszte polecam dowiedzieć się samemu:
http://www.python.org/doc/newstyle.html

Pozdrawiam

[dr_bonzo]

No i jednak... poszedlem na wyklad z Pythona


Co bylo
* ogolny wstep o Pythonie: to ze jest obiektowy, interpretowany
* krotkie omowienie podstawowych typow zmiennych
* duck typing / dynamiczne typowanie (brak typow zmiennych)
* klasy
* funkcje, argumenty, pakowanie arg. do tablic, hashy
* bloki kodu/wciecia
* magia: zmiana metod obiektu, dolaczanie innych klas do obiektu


Jak bylo
Prelegent (czy jak mu tam, wykladowca? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ):
* czasami nie potrafil wyjasnic zgadnien, albo robil to zbyt skomplikowanie
* czesc zagadnien rozumialem tylko dla tego ze znalem je z Rubiego
* trudne zagadnienia jak Generatory (nadal nie wiem co to jest, ale cos jak Bloki/Proc/lambdy z Rubiego), Dekoratory (Javo-adnotacjo-aspekty (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ) zostaly zbyt krotko omowione zeby je zrozumiec
* jak sie pomylil to sie nie denerwowal, po prostu poprawial i kontynuowal ('r' -- dla tych co byli (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) )

[Ace]

Cool, ja walczę z dekoratorami. Musze je zrozumieć na jakimś przykładzie. W necie ciężko znaleźć dobrze omówione dekoratory, może dlatego i on źle to zrobił (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[Jabol]

Odpuście sobie dekoratory? One nie są prawie do niczego potrzebne. Zagadnienia typu dekoratory nie przydają się w zwykłym programowaniu.

[sztosz]

A mi się bardzo podobało to jak zmieniał klasę obiektu, mając już jego instancję (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Nagle się okazało że "klasy abstrakcyjne" to coś, co zupełnie nie jest potrzebne (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Bo możesz dołączyć do jakiegoś obiektu inną klasę, a raczej jej metody a wszystkie zmienne (jak to się nazywa? Pijanym i pamięć już nie ta) które dany obiekt posiada nie zmieniają swoich wartości. Ja w tym widzę potencjał, zastanawiam się tylko czy:

Kod

self.__class__= NewClass()

zadziała?

A mi się nie podobało to jak gdzieś tam po kropce było 6 zamiast b i się interpreter zbuntował errorem, po czym od razu następne zagadnienie było bez słowa wyjaśnienia :|

Co do generatorów to pamiętam że mi się podobały, ale we Wrocławiu jestem skazany na pijaństwo i nie pamiętam jak to działa i czemu mi się podobało (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

Ten post edytował sztosz 10.05.2007, 18:17:48

[Jabol]

Generator to tak jak iterator tylko nieistniejącej wartości. To taka różnica troszkę jak pomiędzy range i xrange. Iterator iteruje poprzez istniejący zestaw wartości a generator przy każdym kolejnym wywołaniu generuje nową wartość. Tylko nie rozumiem za bardzo w czym różnica, bo iteratory można budować za pomocą generatorów a generatory za pomocą iteratorów... ale jakoś tak to jest...

[Sedziwoj]

Że coś z manuala PHP zacytuję:

These functions allow the dynamic manipulation of PHP classes, at runtime.

Czyli to nie tylko domena Pythona (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[sztosz]

Ale runkit i classkit to są rozszerzenia PECL, czyli idąc twoim tokiem rozumowania protezy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[splatch]

Nagle się okazało że "klasy abstrakcyjne" to coś, co zupełnie nie jest potrzebne (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

Jedna prosta rada. Weź rozpęd i pier* z całej siły łbem w ścianę. Tylko tyle mogę powiedzieć. Do tej pory spotkałem się tylko z jedną dużą aplikacją, w której klas abstrakcyjnych nie było, ponieważ ktoś, kto to pisał zdecydował się na Java Script Pages (taak, to nie pomyłka), w pozostałych przypadkach klasy abstrakcyjne jak i interfejsy były stosowane (Java, PHP). Zwróćcie uwagę - dlaczego Java jest tak rozpowszechniona w środowisku biznesowym. Nie tylko dlatego, że ma zaplecze marketingowe w postaci Suna, nie tylko dlatego, że jest do niej stos bardziej czy mniej użytecznego gotowego kodu, ale dlatego, że oferuje jasną składnię i standardowe mechanizmy (typy generyczne na modłę szablonów w C++, adnotacje na kształt dekoratorów w Pythonie). Wszystkie te rzeczy zostały włączone do "standardowej" Javy, ponieważ był przydatne. A przyznacie chyba, że takie zabiegi w językach kompilowanych nie są częste. Spójrzcie - Java ewoluuje, PHP ewoluuje, a Python co? A Python ma stadko zwolenników, którzy twierdzą, że to język idealny. Bzdura i tyle.

[sztosz]

Proponuje żebyś sam pier* z całej siły łbem w ścianę, jeżeli nie potrafisz pewnego minimalnego "poziomu" zachować i powstrzymać się od "osobistych wycieczek".

Piszesz że Python nie ewoluuje. mam rozumieć że wszelkie zmiany od wcześniejszych wersji są niczym. Zastanawia mnie więc czemu twierdzisz że PHP ewoluuje? Bo się nie dorobił namespces? Bo wciąż są dodawane nowe rzeczy, ale nie jest robiony porządek choćby z nazewnictwem wbudowanych funkcji?

Zaś co do samej kwestii "klas abstrakcyjnych", poza samą teoretyczną czystością kodu wciąż nie widzę czym się różni klasa abstrakcyjna czy interfejs od innych klas. W Pythonie zaś, przy odrobinie wyobraźni i kreatywności można stworzyć taki mechanizm, który będzie tworzył bardzo dynamicznie obiekty odpowiadające dokładnie naszym potrzebom. Chcemy nagle ciężarówkę? Mamy ciężarówkę, chcemy tramwaj? Mamy tramwaj. Pomimo tego że nie ma klas ani ciężarówka, ani tramwaj, ani nawet nadrzędnej abstrakcyjnej "pojazd". Jest jedynie nie abstrakcyjny "pojazd" + do tego zbiór metod z których w czasie już działania aplikacji korzystamy. Żeby uciąć deskę, nie muszę być stolarzem, wystarczy że będę człowiekiem. Pewnie trudno to do objęcia rozumem, a już na pewno ciężkie w implentacji, ale dobrze zaimplentowane jest zgrabne i wydajne.

Mam wrażenie ~splatch, że ty próbujesz wciąż udowodnić że Python jest "Be", bo Java i PHP są lepsze. Jak chcesz to się babraj w swojej hierarchiczności i abstrakcjach, mnie to nigdy nie pociągało. Nigdzie nie twierdziłem że klasy abstrakcyjne są złe czy głupie, a jedynie że mi do niczego nie są potrzebne. To tak jak z muzyką, Hendrix znał 2 skale muzyczne, a był jednym z większych wirtuozów gitary.

[Riklaunim]

Ja Pythona ruszyłem, bo chciałem poznać drugi język, ogólnego przeznaczenia celując na PyQT (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Gdy już się wkręciłem jako tako w ten język odkryłem frameworki Django i Pylons i dość szybko stwierdziłem że to mi znacznie bardziej odpowiada niż PHP. Z frameworków PHPowych znałem dobrze CodeIgnitera ale potrzebowałem czegoś trochę "lepszego". Symfony czy Prado są większe i więcej mogą ale jak dla mnie za dużo na raz trzeba załapać by jako tako poznać te narzędzia (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) W przypadku Django nauka jest bardzo prosta, połączona z licznymi możliwościami i modułami osób trzecich (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Tak więc Django wygrało nad PHPową konkurencją (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Ostatnio też wziąłem się za PyQT4 i też jestem bardzo zadowolony (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) KDE4 pod MS Windows i Maki dodatkowo zapewni przenośne widżety KHTML i inne dodatki (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[splatch]

Proponuje żebyś sam pier* z całej siły łbem w ścianę, jeżeli nie potrafisz pewnego minimalnego "poziomu" zachować i powstrzymać się od "osobistych wycieczek".

Nie znoszę ciemniactwa i krótkowzroczności, które sobą prezentujesz, stąd taka a nie inna, alergiczna reakcja.

Piszesz że Python nie ewoluuje. mam rozumieć że wszelkie zmiany od wcześniejszych wersji są niczym. Zastanawia mnie więc czemu twierdzisz że PHP ewoluuje? Bo się nie dorobił namespces? Bo wciąż są dodawane nowe rzeczy, ale nie jest robiony porządek choćby z nazewnictwem wbudowanych funkcji?

Tak, twierdzę, że Python nie ewoluuje. Co nowego w wersji 2.0 i 2.5? Poprawki i łaty związane z biblioteką standardową, drobne zmiany w API. Naturalnie wynika to z dość pobieżnego przejrzenia changeloga, ale może Ty powiesz co takiego zmienił Python 2.5 i jak wpłynął na pisanie Twoich aplikacji.
Co do PHP - zwróć uwagę, że w PHP4 mechanizmy programowania obiektowego były zbliżone do Pythona (tylko zwykłe klasy), jednakże taki stopień "abstrakcji" był niewystarczający, zatem został on poszerzony w PHP5, do tego dorzucono podpowiadanie typów w sygnaturach metod, SPL, następnie PDO. Wiem, że taki a nie inny obrót spraw wynika z tego, że PHP był na początku strasznie niedorobiony i nieprzemyślany, ale spójrzmy prawdzie w oczy - twórcy tego języka starają się to stopniowo naprawiać i rozwijać język.

Zaś co do samej kwestii "klas abstrakcyjnych", poza samą teoretyczną czystością kodu wciąż nie widzę czym się różni klasa abstrakcyjna czy interfejs od innych klas. W Pythonie zaś, przy odrobinie wyobraźni i kreatywności można stworzyć taki mechanizm, który będzie tworzył bardzo dynamicznie obiekty odpowiadające dokładnie naszym potrzebom. Chcemy nagle ciężarówkę? Mamy ciężarówkę, chcemy tramwaj? Mamy tramwaj. Pomimo tego że nie ma klas ani ciężarówka, ani tramwaj, ani nawet nadrzędnej abstrakcyjnej "pojazd". Jest jedynie nie abstrakcyjny "pojazd" + do tego zbiór metod z których w czasie już działania aplikacji korzystamy.

I po trzech tygodniach wracamy do kodu tylko po to by się podrapać po głowie i powiedzieć "o co (epitet?) tutaj chodzi?". Dynamiczne struktury mają również swoje wady. To tak samo jak z aspektami w Javie - są świetne, dają ogromne możliwości, ale debugowanie kodu z nimi to dramat nie wspominając o refaktoringu. Zmiana sygnatury metody nie wysypuje nam kodu jako takiego, ale wcześniej zdefiniowany pointcut odnosi się do nieistniejącej metody - wynikiem czego - aspekt nie zostanie wszyty - skutkiem czego tracimy część funkcjonalności dodawanej przez tenże aspekt.

Mam wrażenie ~splatch, że ty próbujesz wciąż udowodnić że Python jest "Be", bo Java i PHP są lepsze. Jak chcesz to się babraj w swojej hierarchiczności i abstrakcjach, mnie to nigdy nie pociągało. Nigdzie nie twierdziłem że klasy abstrakcyjne są złe czy głupie, a jedynie że mi do niczego nie są potrzebne.

To, że Ty chcesz sobie stać w tramwaju nie znaczy, że wszyscy również tego chcieć muszą, zatem nie rób zalet Pythona z tego, co nie każdemu się podoba.
W dalszym ciągu podtrzymuje swoje zdanie z poprzedniego posta - stadko fanatyków.

[sztosz]

I po trzech tygodniach wracamy do kodu tylko po to by się podrapać po głowie i powiedzieć "o co (epitet?) tutaj chodzi?".

Odkąd zacząłem dokumentować kod komentarzami nigdy nie miałem tego problemu. A Python ze swoim podejściem do dokumentacji tę sprawę jeszcze bardziej ułatwia.

Dynamiczne struktury mają wady, nie przeczę, ale też sporo zalet które IMHO przyćmiewają wady.

To, że Ty chcesz sobie stać w tramwaju nie znaczy, że wszyscy również tego chcieć muszą

A czy ja kogoś zmuszam? Ty od samego początku twierdzisz że brak "abstract" i "interface" sprawia że język nie nadaje się do użytku. Ale to ty bez tych magicznych słów nie potrafisz połapać się w kodzie, nie ja.

__________
PS:

Nie znoszę ciemniactwa i krótkowzroczności, które sobą prezentujesz, stąd taka a nie inna, alergiczna reakcja.

Próbujesz coś udowodnić tym żałosnym tłumaczeniem? Proponuję zakończyć ten wątek, bo z Pythonem nie ma żadnego związku.

[mike]

Ale to ty bez tych magicznych słów nie potrafisz połapać się w kodzie, nie ja.

No stary, jak Ty nadal widzisz zastosowanie interfejsów i abstraktów tylko do przejrzystości kodu, to zacznij ten wątek czytać od początku, albo poczytaj sobie Wikipedię.

[splatch]

Odkąd zacząłem dokumentować kod komentarzami nigdy nie miałem tego problemu. A Python ze swoim podejściem do dokumentacji tę sprawę jeszcze bardziej ułatwia.

Co takiego niezwykłego jest w Pythona podejściu do dokumentacji? Czy jesteś w stanie odpowiedzieć na pytanie które zadałem wcześniej, mianowicie co w Twoich aplikacjach zmienił Python 2.5 w stosunku do wcześniejszych wersji? Nie chodzi o rewolucję a chociażby o ewolucję. Pokaż mi możliwie dotkliwie jak bardzo Python idzie do przodu a nie stoi w miejscu!

A czy ja kogoś zmuszam? Ty od samego początku twierdzisz że brak "abstract" i "interface" sprawia że język nie nadaje się do użytku. Ale to ty bez tych magicznych słów nie potrafisz połapać się w kodzie, nie ja.

Skreśla go definitywnie, jeśli idzie o duże aplikacje, na potrzeby ww i szybkich fastfoodowych serwisów, może być, z racji na django. Pracowałem w Ciągu ostatnich 2 lat z bardzo zróżnicowanym kodem i wierz mi, że to jest owszem organizacja, ale i dowód tego co programista sobą prezentuje. Kod produkować każdy może, trochę lepiej lub gorzej. Niestety projektowanie to coś więcej niż stukanie w klawisze a rozsądne oddzielenie definicji i abstrakcji od implementacji to klucz do sprawnego rozwoju każdej aplikacji.

[sztosz]

Dobra. Na pewno macie o wiele większe doświadczenie ode mnie. Ja jestem hobbystą teoretykiem, który przez przypadek życiowy musi babrać się w kodzie innych ludzi.

Nie mniej jednak dla mnie przygoda z PHP tak na prawdę skończyła się jakiś czas temu, bo za wiele czasu musiałem spędzać zastanawianiu się jak przetworzyć zamysł w kod (jak się pobawiłem UML było łatwiej). W Javie zacząłem się uczyć na podstawie przykładów, napisałem kilka midletów, ale chyba nadal nie potrafię do końca zrozumieć jak to działa. A w Pythonie potrafiłem jak na razie napisać wszystko to co chciałem, bez zastanawiania się zbędnego czy taka a nie inna struktura, semantyka jest akceptowana przez język. jak na razie Python nie walnął mi przed nogi kłód, o które się potykałem w PHP i czasem w C++.

A patrząc na kod różnych ludzi, mam wrażenie, że to sztuka dla sztuki. Tak jak stosowanie MVC dla prostego "Hello World". Pisząc oprogramowanie nie piszę małego świata który jest rozszerzalny wzdłuż i wszerz, nie jest pięknie poukładany i pogrupowany, ale można się w nim bez problemu połapać i spełnia te funkcję które z założenia miała spełniać. Rozbudowa wymaga pewnej ekwilibrystyki, ale pisząc program do wyłączania kompa o zadanym czasie nie zakładam że może kiedyś będę chciał by mi robił kawę.

I w Pythonie pisanie takich programów przychodzi mi strasznie naturalnie, prosto i bez zbędnej grzebaniny w tonach dokumentacji.

----

Jeśli chodzi zaś o ewolucję to muszę zgłębić poważnie temat by się wypowiedzieć tak kompetentnie jak bym chciał. Porównując zaś do np PHP to w PHP wprowadzano nowe elementy języka też nie za często, a większość tego co ma w tej chwili Python miał od początku. Nie wiem też co rozumiesz przez rozwój? Bo jeżeli wsadzenie PDO do paczki razem z PHP, to to nie jest ewolucja języka a tylko rozbudowa "biblioteki standardowej" o dodatkowe moduły.

A jeżeli chodzi o "interface" i "abstract", to ja naprawdę nie widzę żadnego innego sensu jak przejrzystość kodu. Bo jakmie dla mnie ma znaczenie czy mi przed klasą interfejsu będę miał np. na niebiesko napis "interface", czy będę miał to wyjaśnione w Docstringu? Niech mi ktoś wyjaśni różnicę, bo czytam i czytam i za cholerę nie potrafię jej dojrzeć.

[Jabol]

Chciałem nie odpowiadać, ale nie dam rady. PHP ewoluuje, bo ma stadko dzieciaków, które myślą, że coś potrafią i robią klasy abstrakcyjne i interfejs dla każdej klasy jakie definiują i myślą, że to OOP. A Java jest tak popularna biznesowo, bo jest niezależna od systemu i ma porządną maszyne wirtualną. I Java ewoluuje właśnie dlatego, że ma zaplecze w postaci Suna.

Co do ewolucji Pythona polecam zainteresować się Pythonem 3k, którego specyfikacje zostały zamknięte w kwietniu br. i właśnie trawają prace nad pisaniem. Co do ewolucji w wersjach 2.*. Zupełne przepisanie API obiektów z wersji 2.1 na 2.2, dodanie obiektów nowego typu. Dodanie iteratorów w bodajrze 2.3, potem generatorów. Dalej PDO Python miał *od zawsze*, pisanie w uniwersalnej konwencji to jedna z cech pisania "pythonowego".

Co do niezwykłości Pythonowego podejścia do dokumentacji: w Pythonie dokumentacja jest częścią języka - nie tak jak w innych językach, gdzie dokumentacja to conajwyżej komentarze! Przy wyłączonej optymalizacji, każdy obiekt zawiera swoją dokumentacja jako publiczny atrybut (bardzo się przydaje przy interaktwynych sesjach - które też pomagają w tworzeniu i testowaniu kodu). Od, tyle co do specjalności Pythonowego podejścia do dokumentacji.

A Java też nie jest święta - właśnie się jej ucze i widzę, że jest niekonsekwentna, niespójnie zaprojektowana i na dodatek bałaganiarska. Ale teraz, gdy Java została uwolniona może z następnym wydaniem zacznie się poprawiać:).

Pozdrawiam

Ten post edytował Jabol 14.05.2007, 13:40:51

[splatch]

Panowie rozróżnijmy dwie sprawy - pisanie aplikacji biznesowych od freelancerki i hobby, ponieważ są to dwie różne kategorie oprogramowania, które powstaje na innych zasadach.

Pisząc coś po godzinach, na zlecenie nie trzeba się aż tak strasznie przykładać do jakości kodu, bierzemy django, symfony, cake php, ror czy coś w ten deseń i piszemy, generujemy, bez większego zastanowienia. Taki soft powstaje w przeciągu tygodniu, maksymalnie miesiąca czy też dwóch. Podobnie ma się sprawa z zabawami, typu zegarek, własna obsługa schowka pod Windowsem etc - tutaj nie ma nad czym się rozwodzić i na siłę wpychać jakiejś metodologi, ponieważ mija się to z celem. Sam byłbym w stanie (co zresztą powoli zaczynam robić) bawić się w Django i Pythonie, bez względu na to co Tu piszę i jak bardzo się unoszę nad jedną czy drugą przywarą tego języka.

Obok stoją sobie aplikacje biznesowe, które powstają, niezależnie od stosowanej metodologii bardzo długo, i pisząc to mam na myśli miesiące i lata. Tutaj brak odpowiednich struktur i wyprzedzenia faktów prowadzi do potężnych problemów. To dlatego architekci, analitycy i konsultanci są tak dobrze opłacani, ponieważ potrafią oni patrzeć na aplikację i projekt również pod kontem rozwoju w perspektywie czasu, rozbudowy o dodatkowe, nie zawsze spójne względem całości moduły. Bez odpowiednich mechanizmów, generalizacji całych struktur taki projekt będzie się borykał z ogromnymi problemami tuż po pierwszym odstępstwie od specyfikacji, a znając to z autopsji, następuje to nader szybko i często. Faktem jest, że jakieś (rzadko spotykane) większe i (głownie) mniejsze schody się pojawią.

Tutaj dochodzimy do sedna sprawy, a mianowicie niszy, którą każdy język ma. Powiedzmy sobie szczerze, PHP to ww, Python i Ruby również, z drobnym akcentem na inne zastosowania (Qt?), podczas gdy Java do zwykłych "stronek" to po prostu pomyłka. Stąd PHP, Ruby itd nie zastąpi Javy jak i na odwrót. Nie chciałbym spychać języków interpretowanych tylko do jakiś "niepoważnych" zastosowań, ale prawdą jest, że PHP (Ruby?, Python?) tam dominują.

Być może popełniłem błąd porównując Pythona do Javy, ale błędów uniknąć się niestety nie da.

Co do Javy - specyfika tego języka jest inna, ponieważ jest on kompilowany i komentarze wylatują, z racji na to że to tylko informacja dla developerów. Stąd adnotacje (vide dekoratory w Pythonie), które są pewnego rodzaju trwałą dokumentacją, pozostającą po skompilowaniu do byte-code'u. Dostęp do adnotacji realizujemy przez Reflection API.
Podobnie sprawa ma się w przypadku PHP - możemy pobrać komentarz z poziomu Reflection API (getDocComment dla metod, funkcji, klas jak i pól), acz nie jest to komentarz sparsowany. Swoją drogą, jak wygląda kwestia tagów w dokumentacji Pythona? Czy są one wspierane i czy z poziomu wcześniej wspomnianego atrybutu publicznego można się do nich odwoływać (vide method.__doc__.author)?

[Jabol]

Kod

def func():
   """dokumentacja"""
   kod...
   kod

func.__doc__ == "dokumentacja"
# komentarz to nie dokumentacja

Jak dla mnie Python do stronek to też pomyłka ;P. To jest język skryptowy po pierwsze, ale nie tylko - mogą na nim chodzić całe systemy (patrz - Gentoo). Oczywiście nie ma takich mechanizmów synchronizacji i np działania w sieci jak Java (ojj tak - jak o tym czytam to czuje respekt). Ale do pisania zwykłych użytkowych aplikacji (niezależnie od interfejsu.. swoją drogą Qt jest bee (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ) i bibliotek nadaje się świetnie, tak samo jak do pisania rozległych systemów zarządzania jakimś tam czymś tam (lotniskiem?... w jednej linijce tak jak w Perlu się nie da, ale w kilku więcej na pewno).

Co do dostępu do byte-codu (pakiet asm?) w Javie to to dopiero jest *proteza*. W C też czasami trzeba operować na bytecodzie poprzez asemblera - ale tylko w jednej sytuacji - pisząc shellcody do exploitów i wirusów!! Nigdy poza tym się z tą sytuacją nie spotkałem - nawet nie w bootloaderach!! Także tyle co do mojej opini na temat elastyczności udostępnionej poprzez operacje na bytecodzie (inna sprawa, że Hibernate przewyższa wszystkie ORM dla języków dynamicznie typowanych i inaczej niż w ten sposób by nie powstał - ale przyznajmy - Hibernate dla Javy to Hackowanie samego siebie, żeby ominąc zabezpiezcenia Javy i dostać się na poziom na który potrzeba a którego wirtualna maszyna nie udostępnia).

Pozdrawiam

Ten post edytował Jabol 14.05.2007, 14:17:19

[splatch]

Kod

def func():
   """dokumentacja"""
   kod...
   kod

func.__doc__ == "dokumentacja"
# komentarz to nie dokumentacja

[PHP] pobierz, plaintext 
<?php
/**
 * asdf
 */
class Foo {}
 
$rf = new ReflectionClass('Foo');
echo $rf->getDocComment();
?>
[PHP] pobierz, plaintext 

Jak dla mnie Python do stronek to też pomyłka ;P. To jest język skryptowy po pierwsze, ale nie tylko - mogą na nim chodzić całe systemy (patrz - Gentoo).

W sensie? Jako język dla powłoki systemowej w miejscu Perla?

Co do dostępu do byte-codu (pakiet asm?) w Javie to to dopiero jest *proteza*.

Nie zrozumieliśmy się:

Kod

/**
* Komentarz, którego bytecode nie zawiera
* i adnotacja, do której mamy dostęp
*/
@SuppressWarnings({"unused", "serial"})
class Foo {
    private String foo;

    public Foo(String f) {
        foo = f;
    }
}
// Dostęp do adnotacji
Foo.class.getAnnotation(SuppressWarnings.class).getValue(); // i tutaj dostajemy tablicę

Także tyle co do mojej opinii na temat elastyczności udostępnionej poprzez operacje na bytecodzie (inna sprawa, że Hibernate przewyższa wszystkie ORM dla języków dynamicznie typowanych i inaczej niż w ten sposób by nie powstał - ale przyznajmy - Hibernate dla Javy to Hackowanie samego siebie, żeby ominąć zabezpieczenia Javy i dostać się na poziom na który potrzeba a którego wirtualna maszyna nie udostępnia).

Nie do końca. Większość operacji Hibernate obsługuje przez Proxy, jest to zupełnie normalna strategia pozwalająca na obsługę wywołań dla klas o danym interfejsie. W standardowej wersji Proxy umożliwia tylko obsługę interfejsów, ale jest cglib, który dostarcza tą samą funkcjonalność dla zwykłych klas (swoją drogą niezła bujda: Hibernate is a powerful, ultra-high performance object/relational persistence and query service for Java).
Dostęp do pól, również tych prywatnych, mamy z poziomu Reflection API:

Kod

Foo object = new Foo("asdf");
Field foo = object.getClass().getDeclaredField("foo");
foo.setAccessible(true); // pozwalamy sobie na odczyt wartości
System.out.println(foo.get(object)); // i tutaj dostaniemy "asdf"