[python] Metody korenoveho objektu

Ondra Nekola ondra na twin.jikos.cz
Pondělí Duben 7 09:42:47 CEST 2003


On Sun, 6 Apr 2003, Jan Samohyl wrote:

> Hm, je to pekna blbost, zajimava mozna teoreticky. Hlavni vyhrada je, ze nevidim nic, co by se tim dalo zapsat citelneji nebo
> alespon vyrazne kratceji nez standartne pomoci iteratoru apod. Citelneji myslim to, aby tomu jednak rozumelo vic lidi a
> nemuselo se predtim ucit co to vubec je, nikoli to ze napisu do jedne radky neco co bych normalne napsal na dve. Pokud mate
> protipriklad, sem s nim.

Mam pocit, ze hlavni sila tohohle pristupu je jeho deklarativnost. Protoze kdyz napisu pole.each().msg() tak to rika presne to, co jsem myslel, tedy "posli kazdemu prvku each msg". Ja jsem chtel udelat tohle a ne provadet nejakou iteraci. Jak si tohle jazyk (knihovna) prebere je naprosto jeji zalezitost a muze si to implementovat, jak uzna za vhodne (a tomu rikam zapouzdreni).

Dobre, jako hezky priklad se mi libi neco takoveho (ukradeno, chci rici inspirovano Chipem, prosinec 2002):

def init(server):
	"""Tahle metoda se zavola na zacatku"""
	globalni.autLogin=server.afterDelay(30)
	globalni.autLogin.login("guest","nekdo na nekde.cz")

def loginWithName(server,name, pass):
	"""Tahle metoda se vola, kdyz user vyplni jmeno a heslo"""
	globalni.autLogin.cancel()
	server.login(name,pass)

Osobne mi to prijde jako rozumna metoda, jak programovat objektove. Nemluvim o tom, ze jde vlastne jenom o rozsireni myslenek na funkce vyssich radu a ty jsou imho vcelku bezne (a zvlast v Pythonu).

> Co se tyce implementace, syntakticky to problem neni. V Pythonu lze zakladni objekty (ktery ale neni jen jeden univerzalni)
> podedit a dat jim prislusne metody jako each(), collect(), ktere by pak vratily objekt s prislusnou metodou (treba .close()),
> ktera by pak delala to co se od ni ceka. Akorat by vam pak nesmelo vadit, ze budete psat treba x=muj_slovnik({1:2,3:4}) misto
> x={1:2,3:4}. Ale pak sbohem, efektivito (jak uz to tak u funkcionalniho programovani byva).

Efektivitu nehodlam podcenovat, ale kdybych program chtel myt rychlejsi nez smrt, tak ho budu psat v necem jinem nez v Pythonu a jinak nez objektove. Kdyz uprednostnuju jine aspekty (rychlost vyvoje, snadnost modifikace...) tak imho neni HOM zase tak fatalni volba.

   S pozdravem
       Ondrej Nekola
       ondra na matfyz.cz
       http://www.matfyz.cz/ondra


Další informace o konferenci Python