Názory k článku Objektově orientované programování v Lua

No Python na tom s podporou OOP neni nijak slavne ne? Co treba ta implementace jedinacka, jak by to v Pythonu vypadalo (resp. jeste v jake verzi)?

Nekomu vyhovuje Python, nekomu vyhovuje Lua. Tohle je stejny flame jako napr. Ubuntu Vs Fedora.

Lua Vs Python

odstranilo ti to dvojbodku z URL:

http://lua-users.org/wiki/LuaVersusPython

Možná máte lupy a drbete se podvědomě. Zkuste šampón proti lupům!

Zatím to vypadá tak, že návrh jazyka dělal kdosi, kdo viděl OOP z rychlíku.

Lua neni navrzena jako OO, proto Lua nezna neco jako "tridu". Ale i tak muzeme simulovat spostu vlastnosti trid znamych z jinych OO jazyku za pouziti Lua tabulek a metatabulek(metod).

OOP taky nezná třídy. OOP zná jenom objekty. Některé jazyky si k tomu třídy dodělaly, jiné ne. To je koneckonců čistě jejich věc.

pokud za vlastnosti objektu povazujeme:

1) zapouzdreni
2) dedicnost
3) polymorfismus

tak to samozrejme jde v Lua udelat, jak je v clanku asi na dvou mistech napsano, pomoci tabulek a metatabulek. Resp. ten polymorfismus mame diky dynamickemu typovani zadarmo, takze zbyva "jen" zapouzdreni a dedicnost.

Na to, ze Lua vlastne neni vubec navrzena jako OOP jazyk, je docela zajimave, co vsechno zvladne, takovy miniaturni Lisp :-)))

Tak s touto kanonickou definici je Lua plne kompatibilni :-) Osobne taky moc nechapu prilisne lpeni na dedicnosti, ale C++ a Java jsou na ni castecne postaveny, tak asi proto.

Proč myslíte?

Protože konstrukce Complex.print má k objektům hodně daleko. Jedná se spíše o vytvoření jmenného prostoru Complex. Bohužel tento jmenný prostor není asociován s vytvořenou proměnou self. Navíc ani nelze mluvit o polymorfismu, protože již v okamžiku napsání Complex.print lze na 100% určit jaká funkce bude zavolána. Complex.print má k objektům asi tak blízko jako konstrukce Complex_print(struc_complex* self) v C.

Konstrukce c1.print má k objektům o hodně blíže, protože za běhu se bude vyhledávat metoda "print" v asociativním poli (=polymorfizmus). Tudíž lze mít kontejner s complexními čísly a stringy a volat pro všechny položky kontejneru x.print bez ohledu na typ objektu. (Předpokládáto definici objektu string s metodou print )

Radikální fandové OOP by Vám, ale potvrdili, že k naplnění skutečného OOP je potřeba aby systém uměl poslat libovolnou zprávu (volání funkce) objektu a ten jí uměl zpracovat. Například pošlete zprávu xyz objektu kontejneru ( kontejner.xyz ). Kontejner se podívá zda všechny objekty jsou schopny odpovědět na tyto zprávu a pokud ano pak jim tuto zprávu postupně přepošle. Ačkoliv kontejner nemá nadefinovanou funkci xyz a nikdy o ní neslyšel, přesto je schopen toto volání zpracovat. Pokud Vás zajímá, který jazyk toto umí podívejte se na ObjectiveC Ruby nebo Lisp (CLOS). Lua toto asi nikdy mít nebude. Leda že by se každé volání funkce nějak opisovalo. Např methodcall(objekt,"metoda",parametry,...).

Zdravim,

ad prvni dva odstavce - to si ukazeme priste, v dnesni casti serialu uz na to nebylo misto, v Lua to lze resit pres asociativni pole a s malou pomoci metatabulek.

ad treti odstavec - podle me by to taktez slo v Lua implementovat. Napadlo me zmenit metametodu __index tak, aby nevracela primo asociativni pole (jak tomu bude v pripade odstavcu 1 a 2), ale misto toho si zjistila, zda ten klic (=nazev metody/zpravy) skutecne existuje a zda je typu funkce (nikoli atribut) a podle toho se zachovala. Je to vyhodnocovane v runtime, tj. stejne jako ve zminovanych jazycich, ale musel bych si to odzkouset.

Praktických pohledů na OOP je vícero a žádný bych "nekanonizoval". Za dva hlavní a zároveň dosti odlišné pohledy na OOP bych označil Smalltalk a CLOS. Zatímco první je modelovým příkladem toho, co tu píšete Vy, druhý OOP realizuje zcela odlišně. Stavět vedle sebe ObjectiveC a LISP je dle mého názoru značně zavádějící, protože ObjC je právě příkladem smalltalkovského přístupu - tj. zapouzdření dat a metod a zpracovávání zasílaných zpráv objektem. CLOS na to jde ale úplně jinak - žádné zprávy se tam nikomu neposílají a i to zapouzdření je spíše symbolické - objekt je tvořen pouze daty, ale metody stojí mimo objekty! Polymorfismus je řešen pomocí generických funkcí.
Píšete, že pokud mne zajímá, který jazyk "to" umí, ať se podívám třeba na ObjC nebo LISP. Jenže - umí "co" přesně? Přísně vzato, to, co popisujete (tedy to, co tvrdí "radikální fandové OOP"), právě CLOS neumí. Jenže to, co tvrdí radikální fandové, je minimálně o jednu úroveň abstrakce níž, než kde se dá OOP začít teoreticky budovat a rozhodně to není jediná větev, po které se dá při postupné konkretizaci směrem k praktické realizaci z té vyšší úrovně sestoupit.

Máte pravdu s CLOS jsem se spletl. Tam to tak opravdu nejde.

> Praktických pohledů na OOP je vícero a žádný bych „nekanonizoval“.

Opravdu zabavne aneb „to ja prisel s terminem objektove orientovane programovani a musim rict ze jsem tim nemel na mysli C++“ (Alan Kay)

Ta „kanonicka“ definice oop je taktez z jeho ust, doporucuju si od nej neco precist, dost dobre vysvetluje _proc_ zrovna tyhle vlastnosti jsou tak dulezite pro to, co nazval OOP (aneb co budou jazyky ktere je nenaplnuji pravdepodobne postradat).

Nekdy je to spise smutna zalezitost, hlavne po akci se jmenem "Indos". Ale nekteri spravci (vetsinou zapaleni ucitele informatiky) jsou dobri a aktivni, dokazou napriklad vedle "Indosacke" ucebny provozovat i dalsi 1-2 mistnosti s vyrazenymi pocitaci, ktere ziskali z bank atd., dokonce jsem tam videl i neco podobneho tucnakovi :-)