Co si myslíte o OOP?

[Martin]

Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.

Nemusí, přesně ten příklad s proxy je přiléhavý. Prostě vezmu zprávu, aniž bych jí sám rozuměl, a pošlu ji někam dál.

To same je, kdyz ondatareceive(...) zavola nejakyjinyondatareceive(...).

[Reklama]

[Mirek Prýmek]

int nakafunkce(...) { return ERR_NOT_SUPPORTED;}

Na jakoukoli zprávu, ne na zprávu "nakafunkce".

[Martin]

int nakafunkce(...) { return ERR_NOT_SUPPORTED;}

Na jakoukoli zprávu, ne na zprávu "nakafunkce".

nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.

[BaldSlattery]

Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.

A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.

int nakafunkce(...) { return ERR_NOT_SUPPORTED;}

On myslí dynamický dispatch, to by v Javě byla metoda invoke (obdoba forward), z jejíchž parametrů lze vyčíst jméno původně volané metody.

[BaldSlattery]

int nakafunkce(...) { return ERR_NOT_SUPPORTED;}

Na jakoukoli zprávu, ne na zprávu "nakafunkce".

nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.

Nepochopils.

[Reklama]

[Mirek Prýmek]

V Javě to bude standardně na tři řádky kvůli uzavírací závorce.

Trochu jsem hledal příklady a zjevně to moc používaný není. Zaujalo mě tohle:

Under no circumstances should you call the method on the proxy itself since it will be intercepted again by the invocation handler and you will be faced with a StackOverflowError.

https://blog.frankel.ch/the-power-of-proxies-in-java/

Znamená to, že ten objekt nesmí mít jinou metodu než invoke? To by bylo docela hloupý.

Taky, jestli to chápu správně, nemůže vracet primitivní typy.

Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.

Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.

[Mirek Prýmek]

nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.

No a to je prave to michani urovne implementace a urovne jazyka. O implementaci se nebavime. Semantika predavani zprav samozrejme pomoci funkci implementovat jde. Bylo by nesmyslne tvrdit, ze actor model nejde v mainstreamových jazycích implementovat. To samozřejmě jde, jsou to jazyky turingovsky kompletní

[BaldSlattery]

Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.

Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.

Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.

[Kiwi]

Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.

Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.

Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.

Nicméně ten konkrétní příklad, jak na to v Javě, tu zatím nikdo neuvedl. Pouze tu tvrdíte, že to jde.

[Mirek Prýmek]

Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným

Nepamatuju si, že bych tvrdil, že to v Javě neexistuje. Pamatuju se, že jsem explicitně řekl, že nevím. Nejsem na Javu žádný odborník a děkuju za doplnění, byla to pro mě zajímavá informace.

Každopádně to nic nemění na tom, co jsem tvrdil: neexistuje to v tom smyslu, že tyhle - v původním OOP naprosto běžné a základní - obraty v "mainstream OOP" neexistují v tom smyslu, že nejsou v učebnicích, běžně se (zřejmě) nepoužívají, všechno se drtí dědičností. Původně základní skládání a manipulace se selectory se používá málo nebo vůbec.

Stačí se prostě podívat na nějakou základní učebnici SmallTalku a Javy. Jestli tam někdo nevidí zásadní rozdíl ve způsobu řešení problémů, tak je asi zbytečný ho o tom přesvědčovat.

, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.

Ano, v tomhle jsem se mýlil, to uznávám. Má to nějaká omezení a je to specialita, ne obecná vlastnost všech objektů, ale uživatelsky to není tak nepříjemný, jak jsem čekal.

Ještě je taky otázka, co se děje pod kapotou - jestli je tam nějaká performance penalty oproti normálním metodám.

[BaldSlattery]

Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.

Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.

Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.

Nicméně ten konkrétní příklad, jak na to v Javě, tu zatím nikdo neuvedl. Pouze tu tvrdíte, že to jde.

Trochu jsem se tu v té diskuzi ztratil, jaké bylo zadání?

[BaldSlattery]

Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným

Nepamatuju si, že bych tvrdil, že to v Javě neexistuje. Pamatuju se, že jsem explicitně řekl, že nevím. Nejsem na Javu žádný odborník a děkuju za doplnění, byla to pro mě zajímavá informace.

Každopádně to nic nemění na tom, co jsem tvrdil: neexistuje to v tom smyslu, že tyhle - v původním OOP naprosto běžné a základní - obraty v "mainstream OOP" neexistují v tom smyslu, že nejsou v učebnicích, běžně se (zřejmě) nepoužívají, všechno se drtí dědičností. Původně základní skládání a manipulace se selectory se používá málo nebo vůbec.

Stačí se prostě podívat na nějakou základní učebnici SmallTalku a Javy. Jestli tam někdo nevidí zásadní rozdíl ve způsobu řešení problémů, tak je asi zbytečný ho o tom přesvědčovat.

, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.

Ano, v tomhle jsem se mýlil, to uznávám. Má to nějaká omezení a je to specialita, ne obecná vlastnost všech objektů, ale uživatelsky to není tak nepříjemný, jak jsem čekal.

Ještě je taky otázka, co se děje pod kapotou - jestli je tam nějaká performance penalty oproti normálním metodám.

Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům - nepoužívá už ani ve Smalltalku nebo ObjC. Performance penalty tam určitě bude, i v ObjC je forwardInvocation řádově pomalejší (ten prapůvodní účel zahrnoval síťovou komunikaci s ještě mnohem větší latencí, tak to nevadilo). Moderní použití proxy je v ObjC například “animátor”, ale protože je ten mechanismus nesnesitelně pomalý, zrychlili to přidáním forwardingTarget. To už v Javě opravdu není, ale zrovna tohle tam asi nikomu nechybí.

Jinak v Javě se to používá pod kapotou, tj. v podstatě jen v knihovnách, kde to je skryté, takže se s tím BFL normálně nesetká (což je asi spíš dobře).

[Mirek Prýmek]

Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům

Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.

Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?

A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.

[BaldSlattery]

Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům

Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika

To není pravda, i do původního OOP to přidali až v souvislosti s potřebou DO. RespondsToSelector je něco jiného, to tam původně bylo, ale to je jen introspekce. Nicméně hádat se nebudu, jen v podstatě “překládám” z AJ příslušnou pasáž z knihy Object oriented programming přímo od Coxe. Jinak historie “čistého” OOP včetně toho forwardingu za účelem DO je skvěle popsaná v knize Developing business applications with OpenStep, kterou jsem teď taky oprášil, abych si ověřil, co tu píšu. V té je i historický exkurs o probublání mnoha technik z OpenStepu do Javy. Čili závěr je, že buď prapůvodní účel forwardingu byly výhradně distribuované objekty, nebo Brad Cox lže.

[BaldSlattery]

Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům

Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.

Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?

A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.

Jinak další sekundární použití bylo HOM, to se přestalo používat až s příchodem bloků. DO vyšly z módy jako důsledek rozšíření HTTP, takže jediné současné použití je fakt jen ten animátor (to je něco jako doesNotRecognize light, funkčně omezenější, ale zato řádově rychlejší). Ale i to je už skoro historie.