Co si myslíte o OOP?

[Kadet]

Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.

Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.

Tak to asi bude dost záležet na definicích pojmů. Nemám potřebu se o ně přít ani je řešit. To, co je opravdu důležitý, je, že actors komunikují pouze pomocí předávání dat, tj. nesdílejí ani paměť, ani jiné zdroje, čili z principu nemůže nastat race condition jako u OOP, nemusí se používat žádné zběsilé zámky, kritické sekce a podobné srandy. Pořád existuje problém deadlocku kvůli možným kruhovým závislostem, ale to asi žádné extraelegantní řešení stejně nemá (aspoň já o něm nevím).

Jestli dvěma goroutinám, které si posílají zprávy pomocí kanálu někdo chce nebo nechce říkat "dvě vlákna", je mi celkem jedno. Skutečné OS vlákno to může být jenom jedno a žádná tragická performance penalty tam není (btw, stejný princip se používá i v embedded), ani žádné extrabuřthandlery ani jiný "obrovský balast".

Mirku, ten, kdo posila tu zpravu neztraci ihned kontrolu v pripade synchronniho (blokujiciho) volani, jak jsem zminoval. Tj. Tazatel po odeslani zamrzne vyjma toho, ze je schopen prijmout odpoved na svoji odeslanou zpravu. Tazatel a odpovidatel se muzou koordinovat pomoci unikatniho klice (correlation id), ktere svazuje request a response k sobe.

Ano, kazdy agent funguje jakoby plne ve svym pocitaci, s vlastnimi zdroji, ve vlastnim vlakne. Jak moc blizko se tehle abstrakce v softwaru implementujicim agenty/actory dosahne je irelevantni. Konceptualne jsou plne izolovani.

[Reklama]

[Kadet]

Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.

Přiznám se, že vůbec nejsem schopnej dešifrovat, co se snažíš sdělit

Az budu u kompu hodim sem priklad.

Uzivejte Vanoce objektaci!

[Martin]

Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.

Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

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.

[Martin]

Ja jsem nikde nezminil nic o konkretni implementaci frajere.
Mohli bychom zustat v v rovine akademicke diskuse?

[Mirek Prýmek]

Mirku, ten, kdo posila tu zpravu neztraci ihned kontrolu v pripade synchronniho (blokujiciho) volani, jak jsem zminoval. Tj. Tazatel po odeslani zamrzne vyjma toho, ze je schopen prijmout odpoved na svoji odeslanou zpravu. Tazatel a odpovidatel se muzou koordinovat pomoci unikatniho klice (correlation id), ktere svazuje request a response k sobe.

Já teď nevím, o čem mluvíš. Jestli o "mainstream OOP", "původním OOP", actor modelu nebo nějaké své představě. Pokud o actor modelu, tak nemáš pravdu hned v několika bodech.

P.S. tím mým "ztrácí kontrolu" jsem myslel, že nemůže poslat něco ve stylu ukazatel, co by mohl po doručení měnit.

Ano, kazdy agent funguje jakoby plne ve svym pocitaci, s vlastnimi zdroji, ve vlastnim vlakne. Jak moc blizko se tehle abstrakce v softwaru implementujicim agenty/actory dosahne je irelevantni. Konceptualne jsou plne izolovani.

Souhlas - jak je to implementované je irelevantní, pokud jsou splněné jisté požadavky.

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é.

[Reklama]

[Kiwi]

Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.

Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

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.

[Bacsa]

Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.

Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

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.

To je v zásadě pravda, ale otázka je, co pak dělá to ondatareceive.

[Bacsa]

To je pravda, ale jen v rámci jednoho adresního prostoru.

Znova opakuju: v jakém smyslu je to pravda (v rámci jednoho adresního prostoru)?

Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.

[Mirek Prýmek]

Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.

Jak v Javě napíšeš třídu, na které když zavoláš jakoukoli - tj. i v době překladu neznámou metodu, tak ti vrátí string "Sorry, I do not understand"?

Pokud to jde (nevím), tak nějak extrémně krkolomně. Přitom tohle by měl být základ skutečného OOP.

[Mirek Prýmek]

To je v zásadě pravda.

Ne, není to pravda. Bacsa mixuje úroveň jazyka (volání metody vs. předání dat) a jeho implementaci (konkrétní implementace předání dat vs. nějaké to vyhledávání ve virtuální tabulce, ASM CALL apod.)

To, že sémantiku předávání zpráv můžu za nějakých podmínek implementovat pomocí volání metody, neznamená, že je to totéž. Volat můžu jenom metody, které předem znám (jsou v tabulce metod), data můžu předávat jakákoliv a žádnou tabulku k tomu nepotřebuju.

Docela rozumný kompromis je použít oboje - mít tabulku metod, ale zároveň i nějaký fallback, který můžu využít ke zpracování neznámých zpráv (např. Python IIRC).

[BaldSlattery]

Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.

Jak v Javě napíšeš třídu, na které když zavoláš jakoukoli - tj. i v době překladu neznámou metodu, tak ti vrátí string "Sorry, I do not understand"?

Pokud to jde (nevím), tak nějak extrémně krkolomně. Přitom tohle by měl být základ skutečného OOP.

Přes InvocationHandler. Je to stejně “krkolomné” jako ve Smalltalku.

[Mirek Prýmek]

Je to stejně “krkolomné” jako ve Smalltalku.

Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?

[Kiwi]

Je to stejně “krkolomné” jako ve Smalltalku.

Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?

Jen doplním - ve Smalltalku:

Kód: [Vybrat]

doesNotUnderstand: aMessage
    ^ 'Unknown message: ', aMessage asString


[BaldSlattery]

Je to stejně “krkolomné” jako ve Smalltalku.

Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?

Jen doplním - ve Smalltalku:

Kód: [Vybrat]

doesNotUnderstand: aMessage
    ^ 'Unknown message: ', aMessage asString


V Javě to bude standardně na tři řádky kvůli uzavírací závorce. Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.

[Martin]

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;}

To je v zásadě pravda, ale otázka je, co pak dělá to ondatareceive.

Asi se podiva do vstupnich dat, nejak je parsuje a nejak na ne reaguje.