Funkcionální jazyky.

[Mirek Prýmek]

Já bych to udělal pomocí tří rozhraní:
1. Entry -  obsahuje vlastní objekt.
2. Formater - objekt získávající Entry a výsledek bude stream/string
3. Dump - objekt zastřešující vytisknutí libovolného objektu.

Takže třeba: objekt DumpJSON nakrmím formatery, a pak když budu chtít vytisknout Psa, tak se použije PesFormaterJSON.

Může být, o (ne)vhodnost nějakého OOP návrhu se rozhodně přít nebudu Chápu, že v tomhle případě opravdu gettery potřebuješ (nebo použít frienda, což je ještě horší a navíc to jde jenom (?) pro C++).

Pocitově se mi to nelíbí proto, že ti tam vzniká jednoúčelová třída, která musí být napsaný přesně na míru třídě toho daného tisknutého objektu - např. když si vymyslíš novou třídu Mirek, musíš k ní vytvořit MirekFormatterJSON, která bude mít jedinou metodu formatToJSON, kterou bych daleko raději viděl v Mirkovi než kdekoli jinde, protože když bude jinde, zase musím vědět, že vůbec pro Mirka existuje, jak se jmenuje, horko těžko ho budu pro Mirka hledat automaticky... Nevím no, mně se to prostě pocitově (ne-odborně) nezdá

...a mám podezření, že se k tomuhle návrhu uchyluješ v podstatě jenom proto, že přemýšlíš v intencích jazyka, který neumožňuje bezbolestně rozšiřovat existující třídy[1], což by imho pořádný OOP jazyk umět měl

[1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html

[Reklama]

[v]

děkuji kolegové, že jste mi připoměli proč oop nesnáším a proč mám rád haskell

[Mirek Prýmek]

děkuji kolegové, že jste mi připoměli proč oop nesnáším a proč mám rád haskell

Ano, ano, taky jsem se na to upomněl

[BoneFlute]

Já bych to udělal pomocí tří rozhraní:
1. Entry -  obsahuje vlastní objekt.
2. Formater - objekt získávající Entry a výsledek bude stream/string
3. Dump - objekt zastřešující vytisknutí libovolného objektu.

Takže třeba: objekt DumpJSON nakrmím formatery, a pak když budu chtít vytisknout Psa, tak se použije PesFormaterJSON.

Může být, o (ne)vhodnost nějakého OOP návrhu se rozhodně přít nebudu Chápu, že v tomhle případě opravdu gettery potřebuješ (nebo použít frienda, což je ještě horší a navíc to jde jenom (?) pro C++).

Pocitově se mi to nelíbí proto, že ti tam vzniká jednoúčelová třída, která musí být napsaný přesně na míru třídě toho daného tisknutého objektu - např. když si vymyslíš novou třídu Mirek, musíš k ní vytvořit MirekFormatterJSON, která bude mít jedinou metodu formatToJSON, kterou bych daleko raději viděl v Mirkovi než kdekoli jinde, protože když bude jinde, zase musím vědět, že vůbec pro Mirka existuje, jak se jmenuje, horko těžko ho budu pro Mirka hledat automaticky... Nevím no, mně se to prostě pocitově (ne-odborně) nezdá

...a mám podezření, že se k tomuhle návrhu uchyluješ v podstatě jenom proto, že přemýšlíš v intencích jazyka, který neumožňuje bezbolestně rozšiřovat existující třídy[1], což by imho pořádný OOP jazyk umět měl

[1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html

Mno, ve skutečnosti se k tomu uchyluji proto, že:
1. Nesnáším velké třídy. Třída Mirek obsahující metody toJSON, toXML, toAnything mě děsí, a mám s tím zlé zkušenosti.
2. Jestli ten kód napíšu do jednoúčelové třídy, nebo to vlepím do existujícího objektu... tak to radši tu jednoúčelovku.
3. Čistě filozoficky objekt Máslo by neměl umět létat letadlem. (A přesto létá.)
4. Poslední dobou si hodně hraju na kontext. V jednom místě aplikace potřebuju specielní transformaci objektu. Když tuto transformaci zadrátuju do dotyčného objektu, tak to tím zveřejním, a budou to chtít používat všude. To je moc odvážné.

[BoneFlute]

děkuji kolegové, že jste mi připoměli proč oop nesnáším a proč mám rád haskell

Ano, ano, taky jsem se na to upomněl

Co konkrétně? Já se z Haskellu hodně inspiruju, a jeho praktiky používám i v OOP.

[Reklama]

[Mirek Prýmek]

3. Čistě filozoficky objekt Máslo by neměl umět létat letadlem. (A přesto létá.)

Čistě prakticky by bylo fajn umět jakoukoli operaci udělat s libovolným neznámým objektem, to je polymorfismus. Když ti dám objekt X, tak budeš zjišťovat reflexí, jaké je třídy, budeš se dívat do nějakého seznamu, jestli pro tu třídu máš formatter? No nevím

[Mirek Prýmek]

Co konkrétně? Já se z Haskellu hodně inspiruju, a jeho praktiky používám i v OOP.

Já jsem konkrétně dost vystřízlivěl z propagandy, že OOP odpovídá tomu, jak skutečně myslíme. Z toho tvrzení, že OOP-uvažování odpovídá přirozenému způsobu práce s pojmy (Sysel je Savec, Savec je Strunatec...). Když se koukneš na to, o čem jsme se bavili teď, co to má propánakrále společného s (nám) přirozeným způsobem uvažování?!

Ve finále mi přijde daleko přirozenější a přímočařejší uvažování funkcionální, kde je analogie výrobní linka: X jde dovnitř, Y jde ven. Toť vše

[v]

děkuji kolegové, že jste mi připoměli proč oop nesnáším a proč mám rád haskell

Ano, ano, taky jsem se na to upomněl

Co konkrétně? Já se z Haskellu hodně inspiruju, a jeho praktiky používám i v OOP.

na filosofické úrovni bych řekl, že to je jednoduchost a přimočarost - program je tvořen funkcemi, které transformují jedny data na druhé, doslova takto
naproti tomu oop - "posílání zpráv objektů" - co to vlastně je? jistě víme jenom že konsensus neexistuje, patterrny... stav rozházený všude možně.. a tak

[Mirek Prýmek]

naproti tomu oop - "posílání zpráv objektů" - co to vlastně je? jistě víme jenom že konsensus neexistuje, patterrny... stav rozházený všude možně.. a tak

A tak to zas neee! Posílání zpráv je (může být) naprosto jasně definované a pokud skutečně funguje tak, jak se tváří, že funguje, je to ok (Erlang, Elixir). Problém dnešního OOP je mj. v tom, že vychází z logiky posílání zpráv a přitom žádné neposílá, jenom to neuměle kašíruje.

[BoneFlute]

3. Čistě filozoficky objekt Máslo by neměl umět létat letadlem. (A přesto létá.)

Čistě prakticky by bylo fajn umět jakoukoli operaci udělat s libovolným neznámým objektem, to je polymorfismus. Když ti dám objekt X, tak budeš zjišťovat reflexí, jaké je třídy, budeš se dívat do nějakého seznamu, jestli pro tu třídu máš formatter? No nevím

Ano budu. To co popisuješ ty, je jako ukazovat na Máslo a říct: "padej do ledničky". Jako některá inteligentnější Másla to umí. Ale když koukám na našeho Psa, tak si říkám, že je někdy jednodužší ho tam dostat ručně (do boudy, do ledničky mu to de).

Mimochodem to s tou reflexí, to nemáš pravdu. Rozdíl mezi tím tvým a mým je pouze umístění. Stejně jako mě může scházet formater, tak tobě může ten objekt to které formátování neumět.

[v]

naproti tomu oop - "posílání zpráv objektů" - co to vlastně je? jistě víme jenom že konsensus neexistuje, patterrny... stav rozházený všude možně.. a tak

A tak to zas neee! Posílání zpráv je (může být) naprosto jasně definované a pokud skutečně funguje tak, jak se tváří, že funguje, je to ok (Erlang, Elixir). Problém dnešního OOP je mj. v tom, že vychází z logiky posílání zpráv a přitom žádné neposílá, jenom to neuměle kašíruje.

může, není, do teologie se (dneska večer) nepouštím

[Radek Miček]

3. Čistě filozoficky objekt Máslo by neměl umět létat letadlem. (A přesto létá.)

Když ti dám objekt X, tak budeš zjišťovat reflexí, jaké je třídy, budeš se dívat do nějakého seznamu, jestli pro tu třídu máš formatter? No nevím

Nešlo by to řešit tak, že by se formatter do funkce předal společně s objektem X (to může udělat i kompilátor automaticky - v Haskellu se k tomu používají typové třídy, ve Scale implicity, v Rustu traity)?

[Mirek Prýmek]

Ano budu. To co popisuješ ty, je jako ukazovat na Máslo a říct: "padej do ledničky". Jako některá inteligentnější Másla to umí. Ale když koukám na našeho Psa, tak si říkám, že je někdy jednodužší ho tam dostat ručně (do boudy, do ledničky mu to de).

Jak jsem říkal, (už) nevěřím tomu, že OOP přímo souvisí s reálným světem a nevěřím argumentaci analogií z reálného světa. Kdybych si z toho chtěl dělat srandu (což vlastně chci! ), tak lednička taky nefunguje tak, že když z ní chceš něco vzít, tak se staneš ledničkou, něco si tam vezmeš, pak se staneš zpátky BoneFlutem a juchů, máš to v ruce! A přitom přesně tohle vlákna v OOP dělají...

Mimochodem to s tou reflexí, to nemáš pravdu. Rozdíl mezi tím tvým a mým je pouze umístění. Stejně jako mě může scházet formater, tak tobě může ten objekt to které formátování neumět.

Ne. Pokud formátovací kód neexistuje, tak neexistuje, v tom se ta dvě řešení neliší a lišit nemůžou. Maximálně můžeš mít obecný formatter, ale to já taky (objekt metodu nepodporuje? Ok, tady je workaround...) Jediný skutečný rozdíl je přesně v tom, kde ten kód leží - já bych ho připlácl k datům, ty bys ho dal někam kdovíkam a pak ho při každé operaci horko těžko zase zpátky hledal. To mi prostě přijde zbytečný, nekoncepční a typicky OOP-přeplácaný. Ale už bych fakt tuhle věc opustil, není to důležitý ani jako offtopic

[Mirek Prýmek]

může, není, do teologie se (dneska večer) nepouštím

No právěže v Erlangu je definované naprosto přesně. Včetně toho, jak se to chová v konkurentním prostředí, jak se zprávy řadí, jak je možné je vybírat atd.atd. Proto na posílání zpráv není nic špatného, akorát musí být prostě implementované dobře.

Nešlo by to řešit tak, že by se formatter do funkce předal společně s objektem X (to může udělat i kompilátor automaticky - v Haskellu se k tomu používají typové třídy, ve Scale implicity, v Rustu traity)?

To asi nějak šlo, ale já právě mluvím o situaci, kdy ten formatter nemám. Např. deserializuju objekty ze souboru a chci do html vypsat jejich seznam. Čili pro každý objekt pak budu horko těžko hledat vhodný formatter. Haskell bych do toho netahal, já se vymezuju proti konkrétnímu řešení v konkrétním "mainstreamovém OOP".

[Pavel Tisnovsky]

Co konkrétně? Já se z Haskellu hodně inspiruju, a jeho praktiky používám i v OOP.

Já jsem konkrétně dost vystřízlivěl z propagandy, že OOP odpovídá tomu, jak skutečně myslíme. Z toho tvrzení, že OOP-uvažování odpovídá přirozenému způsobu práce s pojmy (Sysel je Savec, Savec je Strunatec...). Když se koukneš na to, o čem jsme se bavili teď, co to má propánakrále společného s (nám) přirozeným způsobem uvažování?!

Nedá mi to a připomenu dnes již starou polemiku mezi p. Viriusem a p.Čadou o tom, jak jsou na tom z hlediska třídního OOP třídy reálných a komplexních čísel. Vyplynulo z toho, že návrh OOP hierarchie není tak jednoduchý, jak by se mohlo zdát (a nepřímo vyplynula poučka, že dědičnost mnohdy přináší víc škody než užitku )