http://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/Wpisy z dziennika internetowego Jogger, wspomaganego przez JabberaSat, 04 Feb 2012 19:41:37 +0100JoggerPLhttp://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/#c232610Oj Pythona, to ty raczej nigdy byś nie polubił. Prawie wszystko z czego się cieszysz, albo czego oczekujesz, to rzeczy za których brak Pythonowcy kochają swój język ;-)No, przeciążania metod (właściwie tylko konstruktorów) mi trochę w Pythonie brakuje... ale rozumiem czemu tak musi być.Mon, 16 May 2005 13:04:35 +0200http://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/#c232610http://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/#c234151Z tego co mówisz i piszesz, to Python może być ciekawy właśnie przez prezentowanie dość odmiennego od Javy podejścia do programowania. Nie uwiódł mnie gdy próbowałem napisać coś w PyGTK, ale i nie odstraszył. Ma zabawną notację, jeszcze do niego wrócę, może jak przemielę podstawy XUL+Scriptable.To, o czym mówiłeś dziś, tj. ducktyping (?) całkowicie mnie zadowala. Mogę spokojnie przyjąć dynamiczne typowanie jeśli mam gwarancję, że wszystkie obiekty implementują _nieformalny_ interfejs, którego się od nich oczekuje w danym zadaniu. Niestety w PHP nie jest to realne, bo tu dzieje się wszystko w rantajmie i na sprawdzenie jest zawsze za późno.A tak poza tym, co złego jest w definiowaniu interfejsu?Wed, 18 May 2005 14:47:09 +0200http://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/#c234151http://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/#c234161Chociażby to, że nigdy nie wiesz jakiego dokładnie będziesz potrzebował. Powiedzmy, że masz obiekt operujący na plikach. Różne jego metody przyjmują jako argumenty pliki. Czyli można by zdefiniować interfejs "IFile", który implementowałby, powiedzmy, metody read(), write(), seek(). W takim przypadku ktoś może w swoim obiekcie, pełniącym rolę pliku, zrealizować interfejs IFile i używać teog obiektu zamiast pliku. Ale po co implementować wszystko, jeżeli obiekt jest tylko czytany? To co, trzy interfejsy? IReadableFile, IWrittableFile, ISeekableFile? Do tego cały zestaw interfejsów pochodnych, jeżeli język nie pozwala na podawanie zestawu interfejsów w sygnaturze metody (np. ReadableFile+ISeekableFile)?A może zdefiniować zachowanie niezaimplementowanych metod interfejsu IFile? Ale przecież to już ma zdefiniowane interfejs każdego obiektu w Pythonie — wyjątek AttributeError.Jednak też nieprawdą jest, że w Pythonie zupełnie nie ma interfejsów. Jest kilka implementacji takich mechanizmów, używanych tam, gdzie okazały się konieczne, np. w dużych frameworkach, jak Zope. Wszystko przy wykorzystaniu istniejących, udokumentowanych cech języka.W świecie Pythona większośc interfejsów jest umownych, ale to działa. Sama rozszerzalność języka oparta jest o takie umowne interfejsy. Jeżeli obiekt ma metody __getitem__() i __contains__() (no, jeszcze kilka dla kompletu), to już może być używany jako słownik. Jeżeli ma metodę __call__(), to jako funkcja, itd. itp. Inna sprawa, że w większości przypadków nie trzeba tego wszystkiego implementować od zera, bo teraz w Pythonie można dziedziczyć po dowolnym wbudowanym typie (łącznie z integerem, funkcją, czy klasą). To po prostu trochę inna filozofia niż w językach ze statyczną kontrolą typu, jak i tych typowo-skryptowych ze słabym typowaniem (bash, tcl, perl, php).Wed, 18 May 2005 15:05:42 +0200http://stronger.epsi.pl/2005/05/16/behind-jaggi-lines-pt.-ii/#c234161