Dědičnost dnes

Re:Dědičnost dnes
« Odpověď #555 kdy: 29. 01. 2017, 19:42:49 »
Proc je enkapsulace tak dulezita? Z perspektivy nekoho, jako je Armstrong, zastance funkcionalniho programovani, to nedava smysl, protoze data jsou immutable (jinak receno, pracuje se s hodnotami, nikoli s promennymi).
Jenom tak pro zajímavost: ono je to ještě trochu zamotanější: Erlang má enkapsulaci taky - pokud mám uvnitř nějakého procesu nějaká data, ale proces nemá implementovanou žádnou zprávu, na kterou by je vydal, tak se k nim nejde žádným způsobem dostat. Je to v podstatě úplně to samý jako private u OOP, spíš ještě striktnější. Kromě toho existuje ještě jeden způsob skryvání dat, který je standardní: procesu se neposílá přímo zpráva, ale zavolá se funkce z příslušnýho modulu (takže přesně nevím, co se vlastně procesu posílá, je to ode mě odstíněný).

Předpokládal bych, že Armstrong by nekritizoval enkapsulaci per se, ale spíš její dogmatické využívání všude a na všechno a nikdy jinak.

Jinak ale máš naprosto pravdu v tom, že když mám data striktně imutabilní, nemusím s nima dělat takové caviky a můžu je klidně i zveřejnit, protože mi je stejně nikdo nemůže změnit.
« Poslední změna: 29. 01. 2017, 19:45:02 od Mirek Prýmek »


v

Re:Dědičnost dnes
« Odpověď #556 kdy: 29. 01. 2017, 19:49:53 »
Jinak ale máš naprosto pravdu v tom, že když mám data striktně imutabilní, nemusím s nima dělat takové caviky a můžu je klidně i zveřejnit, protože mi je stejně nikdo nemůže změnit.
reálně ale nastávají situace, kdy to je problém, funkce (typicky knihovní) potom moc nemůžou předpokládat nějaké vlastnosti argumentů (setříděné pole, vyvážený strom, velké prvočíslo, ...), v haskellu se to řeší neexportováním kostruktoru

balki

Re:Dědičnost dnes
« Odpověď #557 kdy: 29. 01. 2017, 19:53:03 »
JS, poprosim k Vasim tvrdeniam literaturu. Funkcionalne programovanie je momentalne moje hobby, a rad by som si teda precital.
  • o tom, ako je enkapsulacia zbytocna
  • ako robi FP zo vzorov trivialne veci, co nemaju pomenovanie
  • ako robia abstrakcie funkcionalneho programovania objektove abstrakcie zbytocnymi

Potom budem schopny polemizovat, lebo zatial nechapem suvislosti.

Dakujem :)

Re:Dědičnost dnes
« Odpověď #558 kdy: 29. 01. 2017, 19:53:29 »
Ach jo. Tento akademický pseudoproblém je dobrý jen k tomu, aby poukázal na fakt, že v různých případech se mohou hodit různé přístupy. Ne, že jeden je dobře a druhý špatně, nebo snad že to je neřešitelný problém. Tím méně to představuje problém u matic. Takže znovu:
Se čtvercovou maticí mohu dělat všechno co s obecnou a pár operací navíc.
Já bych ani neřekl, že je to pseudoproblém. Není to náhodou spíš narážka na to, že můžu mít objekty/třídy A a B, které se mi zdají nějak související/podobné, ale z nějakého pohledu má A o pár vlastností navíc, z jiného má o pár vlastností navíc B a do toho všeho nejsem schopný jejich společnou podmnožinu nějak rozumně nazvat?

Jinými slovy: modelování světa do stromu, kde děti mají vždycky jenom jednoho rodiče a vždycky se jenom specializují, je prostě trochu problematický, reálnýmu světu to moc neodpovídá ;)

gll

Re:Dědičnost dnes
« Odpověď #559 kdy: 29. 01. 2017, 20:05:30 »
Psal jsem, že to je jedna z možných implementací. Jiná je např. taková, že matice má přístupové metody k svým blokům a vektor může být generován dynamicky (klidně i bezinstančně).

Neni mi uplne jasne, jak si to predstavujes, protoze ta implementace vektoru muze treba predpokladat, ze prvky jsou v pameti za sebou. Pak bude muset ta matice pro radek nebo sloupec ten vektor explicitne vytvorit.

Matice 1xn, nebo nx1 je v paměti stejná jako vektor (při běžné husté reprezentaci). Obsahuje navíc jen informaci o tvaru. Taková matice, může umožňovat konstrukci z vektoru a mít nějakou metodu as_vector. Pro násobení stačí vektor převést na matici.


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #560 kdy: 29. 01. 2017, 22:21:50 »
Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.

To neni uplne idealni, protoze ta matice bude muset pro dany radek/sloupec vytvorit novy vektor.
Nebude, stačí vytvořit něco jako view nebo slice nad jedním řádkem nebo sloupcem (nebo obecně pro podmatici). Úplně nejlepší by ovšem bylo mít jen typ tenzor a veškeré potřebné operace definovat pomocí násobení tenzorů, pak stačí jedna implementace pro vše včetně skalárního součinu. Jediný problém je se skaláry, ty jsou teoreticky taky tenzory, ale implementačně moc ne.

Kiwi

Re:Dědičnost dnes
« Odpověď #561 kdy: 30. 01. 2017, 01:28:32 »
Psal jsem, že to je jedna z možných implementací. Jiná je např. taková, že matice má přístupové metody k svým blokům a vektor může být generován dynamicky (klidně i bezinstančně).

Neni mi uplne jasne, jak si to predstavujes, protoze ta implementace vektoru muze treba predpokladat, ze prvky jsou v pameti za sebou. Pak bude muset ta matice pro radek nebo sloupec ten vektor explicitne vytvorit.

Cela pointa je, ze proste vektory a matice nejsou nezavisle a neni dost dobre mozne implementovat jedno bez znalosti implementace druheho. Jak rikam, pokazde, kdyz potrebujes implementovat nejaky algoritmus, jde to proti skryvani dat.

Možností je více. Matice např. může poskytnout nějaký vhodný iterátor pro přístup ke svým prvkům. Vektor může jít zkonstruovat s pomocí takového iterátoru, pomocí něhož si bude prvky příslušné (sub)matice obstarávat přímo od ní skrze něj.
Tím skrýváním dat v OOP se myslí skrývání jejich implementace, nikoli dat jako takových. Myšlenka je taková, že mám-li objekt řetězec, je jeho konkrétní implementace (např. jako pole bajtů v nějaké konkrétní podobě nějakého konkrétního kódování, nebo navíc třeba i nějak zkomprimované, zašifrované, opatřené CRC a co já vím, co ještě) skryta. Ale rozhodně to neznamená, že bych se k tomu řetězci nemohl dostat. To by bylo poněkud... nepraktické.  :)

Ach jo. Tento akademický pseudoproblém je dobrý jen k tomu, aby poukázal na fakt, že v různých případech se mohou hodit různé přístupy. Ne, že jeden je dobře a druhý špatně, nebo snad že to je neřešitelný problém. Tím méně to představuje problém u matic.

Ja souhlasim, ze je to pseudoproblem, protoze OOP je pseudoreseni.

Zase, v FP na to bude primocara odpoved. Budeme mit typ (pripadne typovou tridu) matice, a typ ctvercova matice, a funkci, ktera nam z matice vyrobi ctvercovou matici (napriklad otestuje, ze je ctvercova). Nepotrebujeme vyvolavat dedicnost.

Ale v OOP přece taky ne, pokud by to nebylo k ničemu. Už to tu píšu asi tak potřetí, že odvodit podtřídu je v daných příkladech jen jedna z možností. Vhodná-li, to by záleželo na konkrétním kontextu. Zrovna tak tu můžeme hloubat, jak řešit (anti)symetrické matice, (tri)diagonální matice atd., ale nic nevyhloubáme, protože takto obecně se o tom moc říci nedá. Takový je zkrátka život, že na jednu věc se dá dívat z různých stran.

Tak ji přidám přímo do té třídy.

Pokud tu tridu muzes kdykoli zmenit, postrada ten koncept tridy smysl. Byl to jisty slib OOP, ze budou ty tridy "znovupouzitelne", tzn. nebudu je muset menit, abych je mohl treba rozsirit. To tady porusis.

Pokud k tomu rozšíření nepotřebuji znát implementační detaily dat oné třídy, půjde ve většině případů o kompozici. Tato otázka se ovšem nedá rozřešit teoreticky, ale jedině případ od případu, protože se silně dotýká optimalizace přístupu k datům.
(v daném příkladu je to další možnost, jak doplnit matici o ten permanent, pokud nechci nebo nemohu upravit původní třídu)

Jinými slovy: modelování světa do stromu, kde děti mají vždycky jenom jednoho rodiče a vždycky se jenom specializují, je prostě trochu problematický, reálnýmu světu to moc neodpovídá ;)

Rozhodně. Jenže na tom taky OOP založeno není, ačkoli si to většina lidí zblbnutých javským a cépluspluskovým pojetím myslí. Objektový program jsou škatulky, které si vzájemně vyměňují zprávy, a pochopení tohoto konceptu zpráv je naprosto klíčové k správnému pochopení celého objektového programování, protože právě v tom vězí celá ta síla a tvárnost.
Velmi správně píšeš, že vztah potomka k rodiči musí být zásadně specializační. A velmi správně píšeš, že to sotva může stačit k modelování problémů reálného světa. Ale je třeba mít na paměti, že odvozování podtříd je jen jedním z pomocných nástrojů objektového modelování.

Re:Dědičnost dnes
« Odpověď #562 kdy: 30. 01. 2017, 06:24:20 »
Rozhodně. Jenže na tom taky OOP založeno není, ačkoli si to většina lidí zblbnutých javským a cépluspluskovým pojetím myslí. Objektový program jsou škatulky, které si vzájemně vyměňují zprávy, a pochopení tohoto konceptu zpráv je naprosto klíčové k správnému pochopení celého objektového programování, protože právě v tom vězí celá ta síla a tvárnost.
No právě. Jenže většina těch nesmyslných nekonečných debat "o OOP" jsou právě debaty o tom co je "správné" dědit z čeho a jestli je "správné" mít k atributům accessory... Prostě nudné, zbytečné pseudoproblémy, které vnějšího pozorovatele vedou k úvaze, jestli (takhle chápané) OOP víc problémů nepřináší, než jich řeší...

Velmi správně píšeš, že vztah potomka k rodiči musí být zásadně specializační. A velmi správně píšeš, že to sotva může stačit k modelování problémů reálného světa. Ale je třeba mít na paměti, že odvozování podtříd je jen jedním z pomocných nástrojů objektového modelování.
Pak nám ovšem vyvstává otázka, jestli neexistují jiné, "neobjektové" způsoby modelování, které problém neřeší elegantněji - protože zprávy mají, (rozumné) zapouzdření mají, reuse kódu mají, ... a navíc ještě nejsou svázané tím, že vlastnosti je možné jenom vršit, ale počítají s tím, že je možné je dle potřeby volně kombinovat (typeclasses, go interfaces apod.) a navíc ještě třeba netrpí problémem mutability, kde musím každou krávovinu zamykat, až se z toho uzamykám k smrti :)

SB

Re:Dědičnost dnes
« Odpověď #563 kdy: 30. 01. 2017, 08:19:11 »
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

To už se tu řešilo - Smalltalk. Mimoto řešení úloh není jen o praxi.

SB

Re:Dědičnost dnes
« Odpověď #564 kdy: 30. 01. 2017, 08:23:05 »
Podle mě je Smalltalk čistý OOP jazyk, a v praxi se používá velice příjemně.
Souhlas, ale není to mainstream. Moje chyba, napsal jsem to blbě, měl jsem na mysli, že se v "čisté" podobě nevyskytuje v mainstreamu. V ObjC je hezké předávání zpráv, ale zase má primitivní typy (protože to je trošku rozšířené C), Swift není dynamický a vlastně mě z těch "velkých" jazyků nenapadá žádný, co by byl (ve smyslu OOP).

Ani nemůže být hlavním proudem, protože OOP navážno je okrajovou záležitostí. Na druhou stranu je neuvěřitelné, že za 35 let nebyl Smalltalk nejen překonán, ale ani dohnán. Svědčí to 1. o jeho nadčasovosti, 2. o stavu SW inženýrství dnes.

v

Re:Dědičnost dnes
« Odpověď #565 kdy: 30. 01. 2017, 08:25:50 »
Podle mě je Smalltalk čistý OOP jazyk, a v praxi se používá velice příjemně.
Souhlas, ale není to mainstream. Moje chyba, napsal jsem to blbě, měl jsem na mysli, že se v "čisté" podobě nevyskytuje v mainstreamu. V ObjC je hezké předávání zpráv, ale zase má primitivní typy (protože to je trošku rozšířené C), Swift není dynamický a vlastně mě z těch "velkých" jazyků nenapadá žádný, co by byl (ve smyslu OOP).

Ani nemůže být hlavním proudem, protože OOP navážno je okrajovou záležitostí. Na druhou stranu je neuvěřitelné, že za 35 let nebyl Smalltalk nejen překonán, ale ani dohnán. Svědčí to 1. o jeho nadčasovosti, 2. o stavu SW inženýrství dnes.
3. že oop je slepá ulička :)

SB

Re:Dědičnost dnes
« Odpověď #566 kdy: 30. 01. 2017, 08:27:13 »
v pythonu, javascriptu a ruby je vše objekt. Znamená to, že tam nejsou primitivní typy?

Tak zrovna Javascript primitivní typy má, tj. není čistý (=zavádí nadbytečný koncept). Pochopitelně by primitivové šli odpárat, aniž by utrpěla použitelnost, ale takhle implementované to prostě není. Python (zcela zbytečně) nemá zapouzdření - třeba by to šlo dodělat úpravou oné metatřídy.

SB

Re:Dědičnost dnes
« Odpověď #567 kdy: 30. 01. 2017, 08:28:28 »
Predavanie "sprav" v smalltalku je tiez len posielanie objektov do inych objetov cez selectory.  Inac povedane volanie metod s parametrami.  Nie je to ziadna objektova magia. Je to to iste co napriklad aj v C++ .

Ty to schytáš :) Ale tak když už tomu nerozumíš, je lepší mlčet (univerzální pravidlo)... #doesNotUnderstand ;-)

Tato odpověď je kompletní.

SB

Re:Dědičnost dnes
« Odpověď #568 kdy: 30. 01. 2017, 08:47:17 »
V JavaScriptu vse objekt neni, ma primitivni typy (akorat se s nim programator skoro nesetkava, protoze probiha "auto-boxing").

No, není to tak úplně pravdou. Nedávno jsem ladil nějakou aplikaci a nevycházelo mi tam pořád porovnání rovnosti booleanů, než jsem si uvědomil, že jeden je primitivum a druhý objekt. Neboxovalo to. Příčinou je ponechání nadbytečného konceptu primitiv.

SB

Re:Dědičnost dnes
« Odpověď #569 kdy: 30. 01. 2017, 08:57:51 »
To je uz ina vec, ze c++ nema tolke moznosti reflexie a nie je dynamicky typovany. Skratka stale zahmlievate fakt, ze posielanie messagov je analogia k volaniu metod. Pokial si spominam, neexistujuci selector je tiez len dalsi pripad selectoru.  Takze nie je potrebne to ponimat ako magiu.

Stranou: By mě zajímalo, kdo vymyslel ten termín "dynamicky typovaný". Je to hovadina. 1. čisté OP typy nemá, takže buďto je třídovaný, nebo má prototypy. 2. Nic se nikde netypuje/netříduje, objektu přijde zpráva a objekt zná/nezná. Nic dalšího tam není, žádné škatulkování.

K věci: Toto vlákno neslouží k vysvětlování základů pure object programming, to by se dalo dělat donekonečna, obzvláště v případě, že si to někdo ani nechce nechat vysvětlit. Obraťte se na literaturu nějakých smalltalkařů (ne javařů!), najdete v ní nejspíš i provedení zasílání zpráv virtuálním počítačem.