Použití Objective-C mimo Apple

[Mirek Prýmek]

Opravdový dynamický dispatch je, když můžu objekt získat jakkoli (např. deserializovat z disku) a poslat mu libovolnou zprávu.

Resp. tohle je spíš už důsledek té opravdové dynamičnosti. Jinak dynamický dispatch je to, co jsem psal výš: dostanu zprávu a podle své logiky na ni nějak reaguju.

[Reklama]

[v]

(offtopic)
zdá se, že je zde mnoho expertů na programovací jazyky, nevíte o nějakém fóru kde se dá rozumně debatovat o vývoji v Haskellu?

[Mirek Prýmek]

(offtopic)
zdá se, že je zde mnoho expertů na programovací jazyky, nevíte o nějakém fóru kde se dá rozumně debatovat o vývoji v Haskellu?

Tady!

...jo vlastně "rozumně"... Tak to nevím )

[Ondra Satai Nekola]

(offtopic)
zdá se, že je zde mnoho expertů na programovací jazyky, nevíte o nějakém fóru kde se dá rozumně debatovat o vývoji v Haskellu?

Beginners a Cafè na haskell.org mi přišly v pohodě.

[Kolemjdoucí]

OOP bylo od začátku založeno na posílání zpráv mezi objekty, to je jeho klíčový koncept.

Četl jsem již dříve a pojmem Objekt se tam označuje něco jako samostatně fungující počítač, zatímco ve Smalltalku je Objekt soubor dat s metodami a metoda byť volaná na základě zprávy se volá v kontextu volajícího. Pro jistotu ještě jednou KayObject != SmalltalkObject. Ve smyslu KayObject dávají zprávy smysl jako asynchronní messaging mezi procesy, vlákna tehdy ještě nebyla a to tedy nemá se Smalltalkem nic společného.

Ne, má to základ v tom, že žádné vtable nebylo potřeba, protože se opravdu zasílaly zprávy, nikoli volaly funkce. Vtable je mrzká snaha emulovat zasílání zpráv pomocí volání funkcí.

vtable je praktická reakce na zmršený koncept SmalltalkObject.

A proč jsou sdílená modifikovatelná data?

Protože hardware neumí dostatečně rychle kopírovat paměť a obě záležitosti jak messaging, tak přepínání procesů/vláken je mimořádně náročné na kopírování paměti.

Tak jistě.

Podpora pro časté praktiky přímo v jazyku je vhodná, o tom není sporu.

[Reklama]

[Mirek Prýmek]

Četl jsem již dříve a pojmem Objekt se tam označuje něco jako samostatně fungující počítač

Ano, přesně tak to bylo myšleno: objekt = samostatná entita. Pořád se mluví o tom, že OOP dobře odpovídá tomu, jak svět vnímáme - jenže to je (jakžtakž) pravda jenom pro to "skutečné OOP" - viz:

Kolemjdoucí řekne Mirkovi: "zvedni ruku!" Mirek to uslyší, rozhoduje se, jestli Kolemjdoucího poslechne, Kolemjdoucí mezitím čte knížku, Mirek posléze ruku zvedne.

vs.

Kolemjdoucí si vleze do Mirka, podívá se, jak se zvedá ruka, zvedne ji, vyleze z Mirka.

, zatímco ve Smalltalku je Objekt soubor dat s metodami a metoda byť volaná na základě zprávy se volá v kontextu volajícího.

Tak detailně SmallTalk neznám, ale pochybuju, že máš pravdu. SmallTalk má plnohodnotný runtime, který může zprávy doručovat jakým způsobem uzná za vhodné. Jestli je to někdy (většinou) prosté volání metody, to je implementační detail, ne vlastnost jazyka. Kdybych chtěl, můžu klidně udělat distribuovanou implementaci (pokud neexituje, nevím), kde to platit nebude.

vlákna tehdy ještě nebyla

Nevím odkdy, ale dneska to rozhodně platí:

GNU Smalltalk uses preemptive green (non-native) threads; that is, multiple Smalltalk processes are run by the virtual machine in one operating system thread.

http://smalltalk.gnu.org/faq/35

Podle mžho skromnýho odhadu se má věc tak, že od začátku byla myšlenka takováhle a pokud se ji podařilo plně implementovat až díky moderním mašinám (protože starší by to nezvládly), tak to na věci nic nemění.

Protože hardware neumí dostatečně rychle kopírovat paměť a obě záležitosti jak messaging, tak přepínání procesů/vláken je mimořádně náročné na kopírování paměti.

Jak Erlang/Elixir, tak Gnu SmallTalk používají non-OS vlákna, takže přepínáním procesů se fakt nemusíš trápit. Si to někdy zkus: pusť si Erlang a v něm padesát tisíc procesů. Zvládneš to i na Raspberry Kopírování je samozřejmě drahé, ovšem od toho právě máme immutable data structures, aby se zas tak moc kopírovat nemuselo

[Kolemjdoucí]

Ano, přesně tak to bylo myšleno: objekt = samostatná entita.

Myšlenka je fajn, ale prakticky nikde se to takto nerealizovalo.

Tak detailně SmallTalk neznám, ale pochybuju, že máš pravdu.

Podle všeho to jede v jednom vlákně.

multiple Smalltalk processes are run by the virtual machine in one operating system thread.

Tedy všechno je synchronní, žádné KayObjekty. Process ve Smalltalku je zjevně stejné šméčko jako procesy ve Win3.1

pusť si Erlang a v něm padesát tisíc procesů. Zvládneš to i na Raspberry Kopírování je samozřejmě drahé, ovšem od toho právě máme immutable data structures, aby se zas tak moc kopírovat nemuselo

Erlang už se trochu blíží KayObjektům, díky immutable.
Immutable znamená nic než neustálé kopírování a nedá se to nijak obkecat.

[Mirek Prýmek]

Myšlenka je fajn, ale prakticky nikde se to takto nerealizovalo.

Ale ano, realizovalo. Říká se tomu actor model a začíná to být populární

Podle všeho to jede v jednom vlákně.

V jednom OS vlákně je spouste green threads. Podobně jako v BEAM (Erlang VM), akorát ten umí využít i víc jader, což GNU SmallTalk asi teda neumí, když to tam píšou.

Tedy všechno je synchronní, žádné KayObjekty. Process ve Smalltalku je zjevně stejné šméčko jako procesy ve Win3.1

To, že to běží v jednom OS vlákně přece neznamená, že to je synchronní. Akorát nad tím jedním vláknem je prostě ještě jeden scheduler, který těm green threads přiděluje čas.

Immutable znamená nic než neustálé kopírování a nedá se to nijak obkecat.

Tohle jsme tady už myslím probírali a nemám potřebu to opakovat

[Kolemjdoucí]

Ale ano, realizovalo.

Actor model se realizoval. Takhle založené OOP zřejmě ne.

To, že to běží v jednom OS vlákně přece neznamená, že to je synchronní.

Tím si buďte jist a mimo jiné proto se v green threads nesmějí používat dlouhotrvající funkce z OS, protože to zablokuje vše.

Tohle jsme tady už myslím probírali a nemám potřebu to opakovat

Bylo by to zbytečné

[JSH]

No právě. Pokud překladač neumožnuje poslat objektu zprávu, o které s jistotou neví, že jí bude objekt rozumět, tak na tom není nic dynamickýho. Opravdový dynamický dispatch je, když můžu objekt získat jakkoli (např. deserializovat z disku) a poslat mu libovolnou zprávu.

Deserializace -> dynamic_cast -> volání?

Jak nad tím teď přemýšlím, tak C++ má alternativu k tomu respondsToSelector pomocí dynamic_cast. Akorát má trochu jinou granularitu a všechny objekty nemají nutně společného předka. Holt nenutí všechno dědit od jedné bázové třídy.

Nemusíš je nutně kuchat. Tvůj objekt může být třeba wrapper kolem jiného objektu. Dostaneš zprávu, pomocí respondsToSelector zjistíš, jestli ji obalovaný objekt umí zpracovat a pokud ne, tak něco uděláš, třeba si dáš nohy křížem

A pokud ne, tak co? Bez kuchání si ji můžu akorát tak dát vycpat. Co kdybych tu zprávu poslal přímo původnímu objektu a vybodl se na celý wrapper?

Příklad už zazněl: univerzální proxy. Univerzální wrapper, rozšiřující funkcionalitu nějakého objektu o nové zprávy. Objekt, který přepíná dvě implementace - jednu pro případ, že máš připojení na net, jinou pokud nemáš. Atd. atd. atd. Příklady použití lidi neznají a nikde se o nich nepíše právě proto, že v tom zparchantělým C++ a jeho derivátech se to tak napsat nedá

Dobře, upřesním dotaz. Nezajímá mě Co?, zajímá mě Proč? Jaké je využití pro univerzální proxy, co jen přeposílá? Vždycky když jsem psal nějaký mezikus, tak jsem napasovával různá rozhraní.
Stejně tak ty wrappery. Když občas píšu nějaký wrapper, tak holt těch pár trampolín napíšu ručně. Je to na pár minut i pro hodně velké třídy.
Jestli se o nich nepíše spíš proto, že nejsou až tak užitečné.

[čumil]

Pánové pánové. Zase argumentujete o sračkách. Prýmek má pravdu, neměnnost datových struktur právě nevyžaduje skoro žádné kopírování. Ale pod jednou podmínkou, musíme použít rekurzivní struktury. Takže žádné pole, immutable array je nepoužitelný, ale immutable rekurzivní struktura je efektivní. Proč? Při modifikované kopii rekurzivní struktury musíme nově vytvořit pouze páteř dané struktury, která bývá malá (na ni referencemi napojíme zbytek staré verze struktury), no a ani tu páteř nekopírujeme odznova, jen vytvoříme nové reference. Takový ty kecy jak jsou immutable struktury pomalí jdou z tlam amatérů který nevěděj o čem žvaněj. A GC které spravuje jen immutable objekty je mnohem rychlejší než GC které spravuje mutable objekty protože díky neměnnosti dat je možné GC silně optimalizovat. Dám nápovědu protože krom Prýmka by to nikdo nevěděl a začal by fundovaně kecat hovna. Pokud máme neměnná data, je garantováno že data generace X nemohou ukazovat na data mladších generací (X - N) ale pouze jen starších (X + N). A na této garanci je poté GC optimalizováno.

[Mirek Prýmek]

Actor model se realizoval. Takhle založené OOP zřejmě ne.

Actor model je přesně to, jak bylo OOP původně myšleno.

Tím si buďte jist a mimo jiné proto se v green threads nesmějí používat dlouhotrvající funkce z OS, protože to zablokuje vše.

"Synchronní" není totéž co serializovaný. Synchronní volání je takové, u kterého čekám na dokončení operace. Jelikož u C++-like OOP nepředávám zprávy, ale v rámci svého threadu vlezu do objektu, je každé volání implicitně synchronní, pokud nedělám explicitní skopičiny, abych tomu zamezil (v rámci funkce odpálím nový thread, který operaci provede asynchronně).

A přesně tohle je taky ten důvod, proč se současné OOP blbě paralelizuje - protože takovýhle "objekt" je jenom iluze, šidítko pro programátora - ve skutečnosti nemám objekt jako entitu (jako actor) ale jako úplně normální sadu funkcí bez skutečného zapouzdření, do které mi může vlézt libovolné vlákno, kdykoli se mu zachce. Celé to slavné OOP není nic jiného než obyčejná struktura obsahující callbacky a data. Proto taky lidi říkají, že "objektově se dá programovat i v C a C++ na to vůbec nepotřebujete" - páč struktury jsou i v C a nic víc pro tohle není potřeba.

Dlouhotrvající volání samozřejmě OS thread zablokují, ale to je vlastnost OS, s jazykem to nijak nesouvisí, ten zato nemůže. Proto se taky v Erlangu obvykle tyhle věcí řeší pomocí "portu" - samostatného procesu, se kterým se komunikuje rourou (asynchronně).

[Mirek Prýmek]

Jak nad tím teď přemýšlím, tak C++ má alternativu k tomu respondsToSelector pomocí dynamic_cast. Akorát má trochu jinou granularitu

Spíš "akorát je to něco úplně jiného" Úplně správný OOP by mělo umožňovat posílat libovolný zprávy objektu, o kterým vůbec nic nevím. Tj. ne dělat type checking za běhu pomocí nějakých signatur, ale prostě poslat zprávu neznámému objektu na druhé straně planety.

Tady jsme zase u toho "OOP odpovídá intuitivnímu vnímání reálného světa" - pokud do něčeho chci praštit kladivem, tak do toho praštím kladivem ať je to cokoli. Nepožaduju od toho, aby to dědilo z IPrastitelneKladivem

A pokud ne, tak co? Bez kuchání si ji můžu akorát tak dát vycpat. Co kdybych tu zprávu poslal přímo původnímu objektu a vybodl se na celý wrapper?

Wrapper může se zprávou udělat něco rozumného. V podstatě stejně jako něco rozumného můžeš udělat s výjimkou. Např. můžeš mít hierarchii vložených objektů - pokud zprávu neumí zpracovat první, hodíš ji druhému, pokud ji neumí ani on, tak třetímu atd. Přičemž nic o těch vložených objektech nemusíš předem vědět, je to úplně obecný algoritmus vytvářející (opravdový) polymorfismus.

Dobře, upřesním dotaz. Nezajímá mě Co?, zajímá mě Proč? Jaké je využití pro univerzální proxy, co jen přeposílá? Vždycky když jsem psal nějaký mezikus, tak jsem napasovával různá rozhraní.
Stejně tak ty wrappery. Když občas píšu nějaký wrapper, tak holt těch pár trampolín napíšu ručně. Je to na pár minut i pro hodně velké třídy.
Jestli se o nich nepíše spíš proto, že nejsou až tak užitečné.

Ne, nepíše se o nich proto, že obecnou proxy prostě se statickými jazyky udělat nejde, takže to nikoho nezajímá. Využití je např. takové, že držíš referenci na lokální objekt, ale ten ve skutečnosti předává zprávy libovolně kam (např. balancuje do cloudu apod.). Např. ten Elixir má opravdové posílání zpráv a opravdový dynamický dispatch, takže udělat RPC bránu je záležitost vyloženě pár řádek ( https://github.com/mprymek/bertgate/blob/master/lib/rpc.ex ).

Ten příklad se serializací nebyl úplně šťastný, lepší příklad je volání funkce, jejíž název mám uložený ve stringu. V Pythonu to jde. V C++ to buď nejde vůbec, nebo možná nějakou extra speciální berličkou, o které ví jenom Stroustrup a další dva vyvolení na planetě

[ava]

Actor model je přesně to, jak bylo OOP původně myšleno.

To není pravda. Actor model počítá s asynchronním doručováním zpráv (tj. odesílatel nečeká, až bude zpráva doručena a pokračuje ve vykonávání svého kódu), ve Smalltalku (tedy v jazyce, který implementuje OOP tak, jak bylo "původně zamýšleno") je posílání zpráv synchronní (čeká se na odpověď objektu, i kdyby měla být prázdná). To je dost klíčový rozdíl oproti aktorovému modelu.

Jen pro zajímavost, padaly tu otázky na to, jak to má smalltalk s vlákny - vlákna jsou preemptivní, a včetně scheduleru zapouzdřená a přístupná programátorovi (tzn. lze si například implementovat za běhu debugovat a upravovat scheduler vláken - zkuste si to v kterémkoliv jiném prostředí), ale implementačně alespoň ve VisualWorks a myslím že i v Pharu jsou to green threads.

Pozn: Ve smalltalku jsem pár let komerčně dělal, takže trochu vím o čem mluvím.

[Tuxik]

Ten příklad se serializací nebyl úplně šťastný, lepší příklad je volání funkce, jejíž název mám uložený ve stringu. V Pythonu to jde. V C++ to buď nejde vůbec, nebo možná nějakou extra speciální berličkou, o které ví jenom Stroustrup a další dva vyvolení na planetě

Programování se sice už nějakou dobu nevěnuju, ale můžeš mi uvést reálný smysluplný příklad využití téhle fičury? Možná při nějakým skriptování dejme tomu, ale pokud tohle chceš přeložit do strojáku, zkus si uvědomit, co to pro překladač znamená. Mám takový pocit, že do takové situace, kdy se tohle hodí, se můžeš dostat jenom nějakou prasárnou a řešení tímhle způsobem je už jen další prasárna. Ale jak říkám, programování už se aktivně nevěnuju a možná to nějaký smysl má.