Použití Objective-C mimo Apple

[zboj]

Sun microsystems pry chystal nejaky operacni system napsany v jazyku JAVA (snad krome kernelu). Nevite o tom nekdo neco?

Vzhledem k tématu vlákna není myslím od věci menší odbočka: Sun dlouho vyvíjel aktivně i pro Objective-C. Jednak spolu s NeXTem vydal OpenStep (výrazný pokrok oproti NextStepu), jednak prodával software napsaný v ObjC (zejména po akvizici Lighthousu). Až politické rozhodnutí - prosazování Javy - ObjC v Sunu zařízlo. Dost za to mohl i NeXT házením Sunu klacků pod nohy. Sice jim dovolili používat ObjC (jež měli sami licencované od Stepstonu), ale ignorovali jejich žádost o na tehdejší dobu velmi pokročilé vývojové nástroje, hlavně Interface Builder. Kdyby byl býval NeXT vstřícnější, byl by tu dnes možná místo Javy nějaký moderní následník Objective-C.

[Reklama]

[nm]

Jobse vyhodil board.
Apple nevzal Jobse s NeXTem ale koupil NeXT s Jobsem. Nebyl to zadny aquihire, rict si tehdy Be o mensi penize, tak se Jobs nejspis uz nikdy do Apple nevratil.

Co je to "board" a "aquihire"?

[Ondra Satai Nekola]

Co je to "board" a "aquihire"?

https://en.wikipedia.org/wiki/Board_of_directors
https://en.wikipedia.org/wiki/Acqui-hiring

[Mirek Prýmek]

Autoři Smalltalku sice pojem OOP zavedli, ale zavedením pojmu končí veškeré jejich zásluhy. V současné praxi používané OOP je dost jiné než jejich představy.

Což je přesně ten důvod, proč současný OOP stojí za starou bačkoru - a to je hlavně "zásluha" C++:

• rozjel se fetišismus dědění, kdy se každá blbina nesmyslně roubuje na dědičnost
• naplno se rozproudilo šílenství vícenásobné dědičnosti
• málem se zapomnělo, co je to protokol (naštěstí Java ho vrátila do hry)
• skoro úplně se zapomnělo na skládání
• úplně se zapomnělo na to, že ve skutečném OOP se mají posílat zprávy, ne volat funkce
• čímžpádem dnešní programátor vůbec netuší, co je to dynamic dispatch. Dnešní špičkový programátor se pozná tak, že to ví, ale neuměl by to použít.

...a protože prakticky všichni dnešní programátoři umí OOP v téhle C++kem zmršené formě, nezbývá než v té zmršenosti buď aspoň částečně pokračovat (aby vůbec byl někdo schopný jazyk použít -> Java), zavést něco, co je natolik dynamické, že to původní myšlenku OOP trochu připomíná (ale má to tímpádem svoje jiné problémy -> Python, Ruby) nebo celé slavné OOP hodit přes palubu (Go), což je vůbec nejlepší, co jde v současnosti udělat.

Ad Objective C: jeden projekt, který se snaží do Objective C zhurta obout v původním duchu, je http://etoileos.com/ Bohužel mají málo sil a přiliš velké ambice, takže vývoj je nekonečný a přestávám věřit, že vůbec někdy bude dotažený do něčeho použitelného

[JSH]

Zahraju si na ďáblova advokáta.

Což je přesně ten důvod, proč současný OOP stojí za starou bačkoru - a to je hlavně "zásluha" C++:

Hlavní důvod, proč je současný OOP na pytel, je ten, že se považuje za stříbrnou kulku a cpe se i tam, kam se vůbec nehodí. A Smalltalk je dokonalý příklad tohohle šílenství :

• Cyklus for je zpráva, která se posílá počátečnímu indexu.
  
• Sčítání je zpráva, co se posílá jednomu sčítanci.
  
• A i jakákoliv jiná operace, která pracuje s více věcmi je zpráva, která se posílá jedné z nich.
  

Pokud máš jenom kladivo (jazyk, co umí jenom posílat zprávy objektu), pak všechno začne připomínat hřebík (prostě nějakému objektu pošlu zprávu). Pokud je objektů víc, pak jeden vyberu. Pokud jsou naprosto rovnocenné, pak jeden stejně musím vybrat. Jden objekt sice ví kulové o tom, co je ten druhý přesně zač, ale to nevadí. Programátor si to pohlídá, napíše si na to testy, nebo to prostě někdy za běhu zdechne (ať žije duck typing).

Inu hovada vzaly C++ a dopadlo to špatně. Kdyby vzaly Smalltalk, tak to dopadne trochu jinak, ale taky špatně.

[Reklama]

[Mirek Prýmek]

Zahraju si na ďáblova advokáta.

Cyklus for je zpráva, která se posílá počátečnímu indexu.

To seš ovšem hodně blbej ďáblův advokát, protože:

1. pokud chceš rychlou enumeraci, tak použiješ normální c-čkový for

2. když je kolekce objekt a chceš pracovat s celou kolekcí, tak logicky posíláš zprávy kolekci, protože s objekty se komunikuje zprávami

3. i když je kolekce objekt, pořád můžeš komunikovat s jednotlivými objekty, pokud chceš: [myArray objectAtIndex:i]

4. objective-c 2 podporuje iteraci: for (NSString* s in myArray) {...}

Sčítání je zpráva, co se posílá jednomu sčítanci.

Opět: pokud ti to vadí, použiješ čistý C. Proto je Objective C tak fajn, že se dá použít cokoli, co C umí.

A i jakákoliv jiná operace, která pracuje s více věcmi je zpráva, která se posílá jedné z nich.

No, tak už to v objektových jazycích chodí

[Mirek Prýmek]

A Smalltalk je dokonalý příklad tohohle šílenství :

Sorry, omlouvám se, tohle jsem přehlídl, mluvil jsem o Objective-C... Pro SmallTalk to platí, no - čistota nade vše

[JSH]

No, tak už to v objektových jazycích chodí

Jo jo, čisté OOP uvažování se perfektně hodí pro hromadu komunikujících černých skříněk. Čím dál od tohohle, tím víc to drhne.
Většinu času programátor nezasílá zprávy černým skříňkám, ale pracuje s abstraktními datovými typy. Představa posílaných zpráv je fajn. Volání metody ale imo daleko líp sedí na různé "poloprůhledné" skříňky.

Pokud chci pracovat se dvěma objekty současně (tím nemyslím kolekci, ale třeba kolizi dvou geometrických objektů), tak je představa posílání zpráv přímo na škodu. Naproti tomu volání dynamicky vybrané funkce pořád pasuje bez nějakých mentálních harakiri. Obzvlášť pokud jazyk neomezuje dynamický dispatch na jediný typ (např. Lisp).

Osobně si myslím, že posílání zpráv skončilo na smetišti dějin celkem oprávněně. Volání metod z rozumně specifikovaných rozhraní je podstatně uchopitelnější a zprávy navrch IMO nepřináší vůbec nic.

A když už jsme u toho :

čímžpádem dnešní programátor vůbec netuší, co je to dynamic dispatch...

Dnešního programátora by to možná zaskočilo, protože on to zná spíš jako virtuální metody. Po drobném vyjasnění terminologie nebudou mít problém ani ti nešpičkoví.

[Mirek Prýmek]

Jo jo, čisté OOP uvažování se perfektně hodí pro hromadu komunikujících černých skříněk. Čím dál od tohohle, tím víc to drhne.
Většinu času programátor nezasílá zprávy černým skříňkám, ale pracuje s abstraktními datovými typy. Představa posílaných zpráv je fajn. Volání metody ale imo daleko líp sedí na různé "poloprůhledné" skříňky.

...a proto je nejlepší jazyk Erlang, resp. Elixir, protože vnitřek skříněk je přiměřeně funkcionální (non-pure) a mezi sebou skříňky komunikují čistě asynchronními zprávami

Osobně si myslím, že posílání zpráv skončilo na smetišti dějin celkem oprávněně.

Neskončilo. Jenom ho C++ umrtvilo a teď všichni marně tápou, jak vlastně dělat paralelismus... No, když se střelím do nohy, tak se pak po dvou chodí blbě

Volání metod z rozumně specifikovaných rozhraní je podstatně uchopitelnější a zprávy navrch IMO nepřináší vůbec nic.

Ale přináší! Asynchronnost s možností explicitní synchronizace jenom tam, kde je potřeba. Nebo třeba stupidně snadnou implementaci obecné proxy - bez toho, aby se člověk zbláznil z nějakých reflexí nebo kdovíjakého dědění kdovíjakých rozhraní...

Dnešního programátora by to možná zaskočilo, protože on to zná spíš jako virtuální metody. Po drobném vyjasnění terminologie nebudou mít problém ani ti nešpičkoví.

Když říkám dynamic dispatch, tak myslím dynamic dispatch a ne nějakou jeho C++ parodii jako virtuální metody. Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám, ne že mi překladač vytvoří v paměti tabulku callbacků... Nemám ekvivalent respondsToSelector a forwardInvocation -> nemám dynamic dispatch i kdybych se na hlavu stavěl...
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtForwarding.html

Ono to je právě všechno ze vším - nemám pořádný dynamic dispatch -> nedá se příjemně používat skládání a proxy -> kašlu na skládání a všude používám dědění -> deeper and deeper into the shit...

[Kolemjdoucí]

Za starou bačkoru to začalo stát až tehdy když se z OOP udělalo náboženství.

Koncept OOP nemá nic společného s konceptem zasílání zpráv, každý může existovat a existují i samostatně.

To proč se donekonečna zmiňuje mylné zasílání zpráv objektům má pravděpodobně základ v tehdejší implementaci virtuálních metod, vtable v roce 1970 ještě asi nebylo známo, takže pro podporu late binding se volání metod pravděpodobně realizovalo přes zmíněné dynamic dispatch a to je blízké konceptu zasílání zpráv.

Co je koncept dynamic dispatch nepřekvapivě znají i v C třeba jako IDispatch::Invoke. Hodila by se k tomu lepší podpora RTTI.

Neskončilo. Jenom ho C++ umrtvilo a teď všichni marně tápou, jak vlastně dělat paralelismus..

Absence předávání zpráv mezi objekty není příčina problémů s paralelismem, tou jsou sdílená modifikovatelná data.

Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám

To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.

[Pan Jan]

Za starou bačkoru to začalo stát až tehdy když se z OOP udělalo náboženství.

Souhlas.

Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám

To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.

Analogický příklad bych vymyslel i ve FORTRANu 77. Přesto bych se neodvažoval tvrdit, že F77 je objektový jazyk.

[Kolemjdoucí]

Přesto bych se neodvažoval tvrdit, že F77 je objektový jazyk.

Však to po vás nikdo nechce, jelikož se jedná o zasílání zpráv :-) Zasílat zprávy jde asi všude.

[Mirek Prýmek]

Koncept OOP nemá nic společného s konceptem zasílání zpráv,

To se velmi mýlíš. OOP bylo od začátku založeno na posílání zpráv mezi objekty, to je jeho klíčový koncept. Že to dnešní programátoři nechápou, to je právě práce C++. Jestli si to nemyslíš, můžeš zkusit Alana Kaye vyškolit o tom, co to je OOP

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Anebo i Joe Armstronga http://www.infoq.com/interviews/johnson-armstrong-oop - pasáž "Is Erlang object oriented?"

To proč se donekonečna zmiňuje mylné zasílání zpráv objektům má pravděpodobně základ v tehdejší implementaci virtuálních metod, vtable v roce 1970 ještě asi nebylo známo, takže pro podporu late binding se volání metod pravděpodobně realizovalo přes zmíněné dynamic dispatch a to je blízké konceptu zasílání zpráv.

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í. Je to rychlé (což byla motivace), ale vede to tam, kam to vedlo.

Absence předávání zpráv mezi objekty není příčina problémů s paralelismem, tou jsou sdílená modifikovatelná data.

A proč jsou sdílená modifikovatelná data? Protože se volají funkce, místo aby se zasílaly zprávy. Protože údajně "zapouzdřené" objekty jsou ve skutečnosti jenom funkce běžící synchronně v tom samém vlákně a zaručeně v tom samém paměťovém prostoru. Chceš-li jinak, musíš kolem toho dělat opičárny jako různé reflexe a pseudoreflexe. Když opravdu posíláš zprývy, je ti jedno, jestli objekt žije na tomtéž počítači nebo na druhém konci planety. Neřešíš žádnou shared memory. Prostě pošleš zprávu objektu. Kdo, jak a kam ji doručí je ti jedno.

To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.

Tak jistě. Když něco v jazyce nejde, vždycky to můžu nějak nasimulovat, alespoň dikud je jazyk Turingovsky kompletní, že... Jak že to říká ta okřídlená věta? Že můžeš Lisp buď přímo použít nebo ho reimplementovat v jiném jazyce? Tady je to stejný - buď použiješ jazyk s dobrou podporou předávání zpráv, nebo ji budeš špatně reimplementovat. A tohle je hodně špatná implementace.

[JSH]

Když říkám dynamic dispatch, tak myslím dynamic dispatch a ne nějakou jeho C++ parodii jako virtuální metody.

A virtuální metody nejsou dynamický dispatch? Dynamický dispatch znamená výběr implementace nějaké operace v runtime. Pokud si index do vtable nazvu selektor, tak se to zas tolik neliší. Akorát překladač nedovolí poslat zprávu, které objekt přímo nerozumí.

Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám, ne že mi překladač vytvoří v paměti tabulku callbacků... Nemám ekvivalent respondsToSelector a forwardInvocation -> nemám dynamic dispatch i kdybych se na hlavu stavěl...

V C++ nemá respondsToSelector IMO moc smysl. Preferuje se to, že se kód nepřeloží před tím že někdy až bude měsíc v úplňku dostane objekt jakousi zprávu, kterou bude muset v runtime kuchat. Nerad píšu unit testy na věci, které může chytit už překladač.

Místo forwardInvocation je sice třeba napsat nějaké ty předávací metody ručně, ale zase odpadá kuchání neznámého NSInvocation v runtime. Pokud je těch metod moc, tak to stejně zavání spíš antipatternem "God Object".

Ono to je právě všechno ze vším - nemám pořádný dynamic dispatch -> nedá se příjemně používat skládání a proxy -> kašlu na skládání a všude používám dědění -> deeper and deeper into the shit...

Mohl bych poprosit o nějaký příklad použití? Představa, že slepím pár objektů dohromady a zprávy jim budu bez nějakých úprav předávat dál, mi jako návrh kapku smrdí. Bez ohledu na to, jestli je to dispatchem nebo děděním.

[Mirek Prýmek]

A virtuální metody nejsou dynamický dispatch?

Je, ale typicky zmršený.

Dynamický dispatch znamená výběr implementace nějaké operace v runtime. Pokud si index do vtable nazvu selektor, tak se to zas tolik neliší. Akorát překladač nedovolí poslat zprávu, které objekt přímo nerozumí.

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.

V C++ nemá respondsToSelector IMO moc smysl. Preferuje se to, že se kód nepřeloží před tím že někdy až bude měsíc v úplňku dostane objekt jakousi zprávu, kterou bude muset v runtime kuchat. Nerad píšu unit testy na věci, které může chytit už překladač.

To je samozřejmě legitimní designové rozhodnutí. Akorát to už pak není OOP tak, jak bylo původně myšleno.

Místo forwardInvocation je sice třeba napsat nějaké ty předávací metody ručně, ale zase odpadá kuchání neznámého NSInvocation v runtime. Pokud je těch metod moc, tak to stejně zavání spíš antipatternem "God Object".

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

Mohl bych poprosit o nějaký příklad použití? Představa, že slepím pár objektů dohromady a zprávy jim budu bez nějakých úprav předávat dál, mi jako návrh kapku smrdí. Bez ohledu na to, jestli je to dispatchem nebo děděním.

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á