Dotaz: Objektové jazyky podporujúce posielanie správ

[hermes]

Už som podobné fórum zakladal aj inde, ale keďže som nedostal uspokojivú odpoveď skúsim štastie aj tu.

Neviete mi poradiť nejaké jazyky, ktoré pri objektovom programovaní používajú namiesto volania metód

posielanie správ

(message passing)? Potreboval by som to pre inšpiráciu.

Ak nič nevymyslím použijem syntax z Objective C, ktorá mi ale príde trošku nepraktická trebárs:

poslanie správy v Objective C

[stvorec setSize: [stvorec getSize] * 2];

volania metódy (resp getteru a setteru v JS):

stvorec.Size *= 2;

ak teda použijeme takúto triedu:

class Stvorec {
  private size = 10;
  get Size() { return this.size }
  set Size(value : number) { this.size = value; }
  ...

Odpovědi

[Andrej]

Smalltalk… A pak je několik dalších jazyků, které sice většinou nejsou považované za ilustrativní příklad v tomto ohledu, ale message passing mají (bez lámání přes koleno).

[hermes]

Poznám trochu aj smalltalk (zápis posielania správ je podobný ako v Objective C) a poznám aj niektoré actor based jazyky. Žiaľ ja som hľadal práve niečo úplne iné.

Vymýšľam totiž OOP styntax do môjho jazyka a sanžil som sa posielanie správ z Objective C napasovať na môj funkcionálny jazyk (ktorý syntaxou trochu pripomína OCMAL). Chcel som niečo názorné samovysvetlujúce s rýchlym a jednoduchým zápisom ale zároveň aby to zapadalo do ML like syntaxe.

Nakoniec som si po niekoľkých hodinách laborovania vymyslel vlastnú syntax posielania správ a popritom som dostal nápady na zjednosušenie zápisu, ktoré som ešte nevidel v žiadnom inom jazyku, začínam s tým byť konečne spokojný.

[OldFrog {Ondra Nemecek}]

A v čem Vám to nesedí pro Smalltalk vs. funkcionální programování?

[rastos]

Prvá kniha, ktorú som o OOP čítal (v '90 rokoch) vysvetľovala, že objekt je dátová štruktúra obsahujúca dátové členy, ale tiež obsahujúca metódy a zavolanie metódy je znamená "poslanie správy". Zavoláš a.setSize(10) a tým posielaš správu objektu 'a', aby si zmenil veľkosť na 10. Tá terminológia nebola nejak ustálená a preklad tomu moc nepomohol.

Mne sa zdá, že ide len o zápis syntaxe. V čom sa líši "zavolanie metódy" od "poslania správy"? Tak či tak sa nakoniec uložia nejaké parametre na stack cez push, urobí sa call, zmení sa IP register, urobí sa telo metódy a nakoniec sa urobí ret. Žiadne kúzlo tam nie je.

[fe]

Mne sa zdá, že ide len o zápis syntaxe. V čom sa líši "zavolanie metódy" od "poslania správy"? Tak či tak sa nakoniec uložia nejaké parametre na stack cez push, urobí sa call, zmení sa IP register, urobí sa telo metódy a nakoniec sa urobí ret. Žiadne kúzlo tam nie je.

Uvědomme si dobře ten nejdůležitější rozdíl mezi zasíláním zpráv, využívaným v objektovém prostředí, a mezi voláním funkcí, používaném v jazycích C, C++ a podobných: při zasílání zpráv to, jaká operace bude na základě přijetí zprávy provedena, rozhodne až přijímající objekt ve chvíli, kdy zprávu dostal. Protože se takto vazba mezi požadavkem toho, kdo zprávu odesílá, a reakcí toho, kdo ji přijímá, naváže co nejpozději to je možné (tedy až v okamžiku faktického odesílání zprávy za běhu programu), nazývá se tento systém někdy také pozdní vazba (late binding).

Zdroj: http://www.mujmac.cz/rubriky/zaciname-s/objective-c-to-si-vysvetlime-podrobneji-54731cz

[OldFrog {Ondra Nemecek}]

V objektovém prostředí může instance reagovat na všechny zprávy, i na zprávy, které v době překladu neznáte. Třeba je může někam předat. Představte si reflexi, proxy, delegaci, event dispatch, message bus, microservices, agentní systém a podobné věci - takto nějak bylo OOP původně od Alana Kaye míněno.

[luky]

V objektovém prostředí může instance reagovat na všechny zprávy, i na zprávy, které v době překladu neznáte. Třeba je může někam předat. Představte si reflexi, proxy, delegaci, event dispatch, message bus, microservices, agentní systém a podobné věci - takto nějak bylo OOP původně od Alana Kaye míněno.

Nemyslim si, ze je todle neco specifickeho pro objektove prostredi. Kdyz si v perlu definuju funkci AUTOLOAD, tak se mi zavola v pripade volani neexistujici funkce taky a klidne si volani muzu delegovat pres sit na server a zadne objekty nemusim pouzivat.

[OldFrog {Ondra Nemecek}]

Přesně tak, princip je podobný. Akorát v pravověrném OOP byl tento princip povýšen na základní prvek kompozice programů a to v době před uvedením první verze Perlu/Pythonu/PHP. Jinak souhlas.

[petr_p]

On ani ten Perl není zcela neobjektový.

Aby se zavolala metoda AUTOLOAD, když není nalezena volaná metoda, musí někdo zařídit. Zařídí to interpret při směrování volání metod. On to totiž musí Perl dělat tak jako tak, když potřebuje vědět, na jakou funkci z kterého balíku skočit. Takže doimplementovat fallback na AUTOLOAD() namísto zabití programu bylo triviální.

Všimněte, že to funguje jen při volání metod (Foo->bar). Nikoliv při volání funkcí (Foo::bar). Což opět je dáno tím, že se jedná o funkcionalitu z objektové infrastruktury Perlu.

[luky]

Všimněte, že to funguje jen při volání metod (Foo->bar). Nikoliv při volání funkcí (Foo::bar). Což opět je dáno tím, že se jedná o funkcionalitu z objektové infrastruktury Perlu.

Funguje to pri volani funkci ale jen pokud se AUTOLOAD nezdedil:

#!/usr/bin/perl
sub AUTOLOAD {
        print "$AUTOLOAD(@_)\n";
}

blahblah(1, 2, 3); # blahblah neni metoda

Drive bylo mozne definovat UNIVERSAL::AUTOLOAD pokud nekdo chtel autoloadovat funckce z balicku, ale to relativne nedavno vyhodili.

[Sten]

C++ implementuje late binding pomocí virtuálních metod a polymorfismu. Nebo pokud to má být plně dynamické (včetně jmen metod a jejich parametrů), tak se tak chová Python. Způsob zápisu je přitom stejný.

[Bystroushaak]

C++ implementuje late binding pomocí virtuálních metod a polymorfismu. Nebo pokud to má být plně dynamické (včetně jmen metod a jejich parametrů), tak se tak chová Python. Způsob zápisu je přitom stejný.

Late binding v C++ se ale s tím Smalltakovým nedá moc srovnávat, protože nemá smalltalkovské bloky. Ty jsou něco, co staví celý jazyk doslova naruby (jakože fakt doslova, to i obrací fungování většiny konstrukcí, takže vznikají věci jako [a < 1] ifTrue: [ ... ], které jsou plně dynamické ale zároveň přirozené. Dělat něco takového v C++ by bylo pekelně nepraktické.

Co je zajímavé, tak Bluebook (Smalltalk-80: The Language and its Implementation, 0-201-11371-6, celkově fakt doporučuju přečíst) ukazuje jakési hooky, které je možné zavěsit zvnějšku na akt poslání zprávy. Pak když pošleš objektu zprávu, tak dojde automaticky k rozeslání zpráv dalším objektům. Další zajímavá věc, která odlišuje původní ideály posílání zpráv od dnešního chápání konceptu OOP je, že pokud objekt zprávu nenajde, tak dojde k vyvolání metody ala doNotUnderstand: "", která funguje podobně jako __getattr__() a __getattribute__() v pythonu, s tím však že v některých programovacích jazycích je jako parametr přijímám i objekt který zprávu poslal. Reakce na zprávu tak nemusí proběhnout jen formou návratové hodnoty, ale například posláním zprávy (či několika) objektu zpět.

Dost zajímavých myšlenek okolo konceptu posílání zpráv měl Jecel Mattos de Assumpcao Jr, který jeden čas pracoval na verzi Selfu, která zprávy implementovala hardwarem a jejich zpracování mělo probíhat paralelně a zastavovat se jen na místech kde byla skutečně nutná synchronizace.

[luky]

s tím však že v některých programovacích jazycích je jako parametr přijímám i objekt který zprávu poslal

Jak se syntakticky vyjadri, kdo je odesilatel zpravy? Napriklad pokud poslu blok kodu, ktery posle zpravu, je volajici ten, kdo blok kodu evalne a nebo samotny blok?

[Bystroushaak]

To je dobrá otázka a imho by dávalo smysl bloky ignorovat a jít v call stacku tak daleko, že se vybere první ne-blok.

[Sten]

Late binding v C++ se ale s tím Smalltakovým nedá moc srovnávat, protože nemá smalltalkovské bloky. Ty jsou něco, co staví celý jazyk doslova naruby (jakože fakt doslova, to i obrací fungování většiny konstrukcí, takže vznikají věci jako [a < 1] ifTrue: [ ... ], které jsou plně dynamické ale zároveň přirozené. Dělat něco takového v C++ by bylo pekelně nepraktické.

V C++17 tohle jde implementovat celkem rozumně pomocí generických lambd a return type deduction, jen by se ta první lambda musela zabalit do něčeho, co implementuje ty zprávy. Úplně stejně (až na použití jiného druhu závorek) by to šlo implementovat v Kotlinu, tam se dají metody objektům (včetně bloků kódu) přidávat.

Další zajímavá věc, která odlišuje původní ideály posílání zpráv od dnešního chápání konceptu OOP je, že pokud objekt zprávu nenajde, tak dojde k vyvolání metody ala doNotUnderstand: "", která funguje podobně jako __getattr__() a __getattribute__() v pythonu, s tím však že v některých programovacích jazycích je jako parametr přijímám i objekt který zprávu poslal. Reakce na zprávu tak nemusí proběhnout jen formou návratové hodnoty, ale například posláním zprávy (či několika) objektu zpět.

To je ale dvousečná zbraň a důvod, proč se to moc neujalo. Je to totiž hodně náchylné na chyby (překlepy, nedokonalý refactoring, out-of-tree plugin), které nezachytí překladač.

[Kit]

Volání a.setSize(10) je zrovna ukázkou imperativního přístupu, který nemá s posíláním zpráv nic společného. Nedává objektu prostor pro vlastní rozhodování.

[Miloslav Ponkrác]

Ale dává. Dokáži si docela dobře představit, že volání a.setSize(10) zašle objektu a zprávu s názvem "setSize" a parametrem 10. Objekt a si s tím může udělat naprosto co chce.

Pletete si syntaxi a implementací - a to velice drsně!

[Kit]

V tom případě by však název metody setSize() lhal.

Syntaxe říká, že je to v pořádku, ale implementačně to v pořádku není.

[Miloslav Ponkrác]

Nesouhlasím ani s jediným vaším písmenem.

[Kit]

Zápis

a.setSize(10)

je sice syntakticky odlišný od

a.size = 10

ale sémanticky jsou zcela shodné a zpravidla jsou i shodně implementovány. Přitom v OOP není správně ani jeden, protože oba porušují zapouzdření objektu.

[Miloslav Ponkrác]

Šeredně si pletete syntaxi a syntaktický cukr s vlastnostmi a implementací jazyka. Ale opravdu šeredně se pletete.

[Kit]

To je pouhé tvrzení. Mohu požádat o doložení důvěryhodnými zdroji?

Implementací rozuměj to, co napíše programátor.

[Miloslav Ponkrác]

Spíše vy byste měl dokládat a vysvětlovat, co těmi vašimi bludy myslíte.

Vy byste měl dokládat, proč syntaxi a implementaci považujete za stejnou věc.

Vy byste měl dokládat, proč a.setSize(10) nebo a.size=10 by měly porušovat nutně - už se syntaktického hlediska zapouzdření objektu.

Také byste měl dokázat, proč a.setSize(10) nemá s posíláním zpráv nic společného.

Také byste měl dokázat, pro a.setSize(10) nedává prostor objektu pro vlastní rozhodování, co se zprávou udělá.

Měl byste toto všechno doložit.

[Kit]

Nikde jsem neuvedl, že bych syntaxi a implementaci považoval za stejnou vě. Ani náhodou!

Nikde jsem neuvedl, že porušení zapoudření je syntaktickou chybou. To je nesmysl.

Název metody setSize je imperativem, nikoli posláním zprávy. Pokud objekt udělá něco jiného, než nastavení velikosti, jedná v rozporu s kontraktem, který je dán názvem metody. Tedy nikoli chyba syntaxe, ale chyba sémantiky.

[Miloslav Ponkrác]

Ad 1) V tom případě všechny vaše příspěvky nedávají smysl.

Ad 2) Pletete si zapouzdření objektu a syntaxi.

Ad 3) Volání setSize může být cokoli mu tvůrce jazyka určí včetně poslání zprávy. Pokud to popíráte, pak si pletete syntaxi a implementaci. Objekt udělá cokoli, co mu pod zprávou/metodou určí programátor. Jazyku i počítači je to u zadele.

[Kit]

Ad 1) "set size" je příkaz, tedy imperativum. Syntakticky to sice může být zapsáno správně, ale do OOP to nepatří. Kompilátory nekontrolují, zda je něco napsáno objektově či není. Nemají jak.

Ad 2) Kde?

Ad 3) Celou dobu tvrdím, že chybně je název metody setSize() a že ten název do OOP nepatří. OOP je hlavně o schopnosti pojmenovat věci. Pokud je pojmenuješ nevhodným způsobem, svede tě to k chybné implementaci té věci. To znamená, že třeba jen nastaví hodnotu atributu size a myslí si, že je hotov. Kompilátoru je to fuk, smysluplnost názvů nekontroluje, ale programy čtou hlavně lidé!

[Sten]

Čím to porušuje zapouzdření? V Kotlinu

a.size = 10

zavolá setter (metodu) a v jeho implementaci si může objekt dělat, co chce, klidně tu změnu může ignorovat, může vyhodit výjimku a nic nenastavit nebo může odpálit jaderné hlavice.

Je to totéž jako ve Smalltalku:

a setSize: 10

Porušuje tohle zapouzdření?

[Sten]

Python, Ruby, Groovy, všechny dynamické jazyky to mají.

[Bystroushaak]

Smalltalk a Self jsou asi nejznámější případy. O Selfu jsem tu napsal krátký seriál: Prostředí a programovací jazyk Selfu (díl první; prostředí).

[Miloslav Ponkrác]

Prosím vás, jak se syntakticky liší OOP, které zasílá zprávy od těch, které volá metody.

Způsob volání metod není ani tak syntaktická věc, jako spíše věc implementace toho kterého jazyka. Syntakticky to v obou případech (zasílání zpráv, volání metod) může vypadat úplně stejně.

Copak nechápete, že syntaxe jazyka a vnitřní provedení jazyka nemají spolu až tak přímou souvislost?

Zvolte si syntaxi, která se vám líbí, vyhovuje filozofii vašeho jazyka, je blízká vašemu srdci - a nemontujte do toho věci, které s tím nesouvisí.

[Bystroushaak]

Způsob volání metod není ani tak syntaktická věc, jako spíše věc implementace toho kterého jazyka. Syntakticky to v obou případech (zasílání zpráv, volání metod) může vypadat úplně stejně.

Může, ale většinou nevypadá. Například binární zprávy jsou většinou syntakticky řešeny jinak (nepoužívají tečkovou notaci), než ostatní, což v jazycích smalltalkovského typu neplatí.

[Miloslav Ponkrác]

Jinak řečeno jste mi potvrdil, co jsem psal. Syntaxe má jen minimální souvislost s tím, jak se zprávy implementují. Pro autora, co tvoří nový jazyk, tedy není vůbec nutné, aby kopíroval syntaxi jiného jazyka s předáváním zpráv. Protože si tím může naběhnout a je to totální ptákovina.

Syntaxe OOP volání metod a/nebo posílání zpráv více vychází z možností a ostatních vlastností jazyka než z toho jestli je to implementováno tak či onak.

Pokud ten člověk tvoří nový jazyk, měl by to řešit také tak. Tedy syntaxi volání zpráv/metod uzpůsobit zbytku jazyka. Protože syntaxe volání zpráv/metod nijak - zdůrazňuji vůbec nijak - nemusí souviset s implementací.

[Bystroushaak]

Jinak řečeno jste mi potvrdil, co jsem psal. Syntaxe má jen minimální souvislost s tím, jak se zprávy implementují. Pro autora, co tvoří nový jazyk, tedy není vůbec nutné, aby kopíroval syntaxi jiného jazyka s předáváním zpráv. Protože si tím může naběhnout a je to totální ptákovina.

To jsem vskutku nerozporoval. Jak si tím může naběhnout a proč je to ptákovina ovšem úplně nerozumím. Například kaskádovací operátor by podle mého v klasické céčkové notaci působil dost divně.

[Miloslav Ponkrác]

Já jsem se hlavně divím otázce hermese. Protože syntaxe nesouvisí s tím, jak je implementováno volání zpráv/metod. Samotná otázka je chybná.

Já být na místě hermese, tak si nejdříve definuji základní vlastnosti jazyka. A pak teprve začnu dělat něco dále.

[BoneFlute]

Co je to "kaskádovací operátor" ?

[Bystroushaak]

Ve smalltalku je to středník, který říká, že zpráva se má opět poslat stejnému operandu. Kód

obj zpráva.
obj další.

můžeš zjednodušit na

obj zpráva;
    další.

[Sten]

To je ale jenom syntactic sugar. Kotlin má něco podobného pomocí with:

with (obj) {
    metoda()
    další()
}

A C by to klidně mohlo mít taky, kdyby to někdo implementoval.

[BoneFlute]

Jasný. Znám něco podobného pod názvem fluent interface: obj.setFoo(1).setBoo(2).setGroo("abc").do()

Je to to samé, nebo se to něčím liší?

[Kit]

Liší se to tím, že fluent interface se dá snadno zprznit tak, že objekt vrátí něco jiného než sám sebe.

[Bystroushaak]

Jasný. Znám něco podobného pod názvem fluent interface: obj.setFoo(1).setBoo(2).setGroo("abc").do()

Je to to samé, nebo se to něčím liší?

Liší se to hlavně tím, že tady musí všechny metody vracet původní objekt, což v případě kaskád není pravda. Kaskády mi přijdou v tomhle elegantnější, protože tě nenutí přepsat celou svojí knihovnu, přitom ta implementace je triviální. Ale jak psal Sten, není to nic jiného než syntaktický cukr, který ovšem ve Smalltalku šetří dost prostoru.

Osobně se mi i líbí, jak kaskády zapadají do syntaxe Smalltalku.

[BoneFlute]

Díky.