Příspěvky

646

Vývoj / Re:Dědičnost dnes

« kdy: 24. 01. 2017, 13:03:37 »

A FP není superior nad OOP a vice versa, oboje jsou stejně použitelné a silné strategie, každá ale hledí na problém trošku z jinýho úhlu.
Takový ten biologický vs matematický pohled...

...prevest do FP tak, ze misto predavani dat (typicky v nejakych objektech) do jinych objektu budeme predavat funkce (operatory) opacnym smerem. Jinak receno, v OOP vybalujes (delegovanim) vstupni data z objektu, v FP nabalujes (skladanim) funkce, ktere nad daty pracuji.

...Jak uz to tak byva, vyvoj temer vzdy probiha od slozitejsiho k jednodussimu.

Obávám se, že toto je jeden z dalších příspěvků ukazujících nepochopení OOP - data z objektu nejde nijak vybalit, protože když je vybalíte, buďto získáte anemický model, nebo to není objekt (primitivní typy), takže to není OOP. Představa, že by delegace bylo nějaké "vybalování", je úplně nesmyslná.

O FP se tu bavit nechci, neznám jej dost, ale znám OOP a z toho, co tuším o FP (které mi stejně jako OOP většina lidí nedokáže vysvětlit), tak jsou v přímém protikladu - OOP považuje chování a stavy za neoddělitelné a zapouzdřuje je, schopnost modelovat změnu stavů je přímo jeho cílem při zachování identity, FP na samostatná, otevřená data používá samostatné (rádoby) univerzální funkce (či jejich zřetězení), stavy nemodeluje a identitu zahazováním mezivýsledků popírá. Takže v podstatě Čumilovo tvrzení, že OOP a FP spolu nemají nic společného, je pravdivé.
Zbytek příspěvku, co je a není FP, považuju za deklarativní konstrukce či dojmy bez důkazů či příkladů.

V FP je taky "chování" a zapouzdřené stavy, dokonce "zapouzdřenější" než v OOP.

647

Vývoj / Re:Dědičnost dnes

« kdy: 24. 01. 2017, 12:30:58 »

Ctverec vs obdelnik je priklad, ktery ma ukazat obtiznost navrhu OO i na nektere na prvni pohled snadne veci. Neni vubec dulezite, jak to ma byt spravne. (spravne je to tak, ze obdelnik dedi ctverec ).

I kdyz to napsal jak kreten, tak ma pravdu. OOP bylo mysleno jako message oriented programming. Implementace Actor modelu. To, ze si drzi reference na jiny objekt, aby se mu dala poslat zprava (zavolat na nem metodu) znamena, ze kazdy objekt v sobe obsahuje stav cele aplikace (skrz tu referenci).

Pritom kazdy objekt ma byt black box, o kterem idealne nic nevite a on si drzi jen privatni data a komunikuje skrz rozhrani, ale kdyz se zmeni jedna promenna, tak se to promitne v nejhorsim pripade do vsech trid v programu. Kde je pak ta zapouzdritelnost? Problem je, ze tohle neni na prvni pohled videt a prijde zakaznik a zepta se, jak dlouho bude trvat XXX a vy nevite, protoze, kdyz se tim zmeni jen ta jedna trida, tak je to na hodinu, kdyz se tim zmeni vsechno, tak na pul roku.

FP je ted tak popularni, protoze se s immutability mnohem lepe pracuje v multithread systemech, je to snazsi cesta nez vsude davat zamky, resit pristupy. Predej hodnotou a zapomen. Problem vyresen.

1. Obdélník dědí čtverec? To je na vyhození od zkoušky v prvním ročníku

2. Není snad sporu o tom, že ryzí OOP (tak, jak bylo navrženo a implementováno ve Smalltalku a potažmo Objective-C) má řadu výhod a v neposlední řadě je elegantní, nicméně vývoj software je veskrze pragmatická záležitost, takže i pseudo-OOP v C++ má své opodstatnění, jen se hodí na něco trochu jiného. Vrcholem pragmatičnosti pak je Go, jež je sice z akademického pohledu přehnaně osekané, ale v praxi nadmíru užitečné.

3. FP je k OOP ortogonální a ano, má mnohé výhody, a bez něčeho dalšího (OOP) moc praktické není.

648

Vývoj / Re:Dědičnost dnes

« kdy: 22. 01. 2017, 16:33:52 »

Pracujete se zmatením pojmů - to, co jste napsal, není rozhraní. Rozhraní je (už z názvu) jen to, co je vidět zvenku, tohleto je jakýsi hybrid zahrnující i implementaci (má to i Java jako rozhraní s default). Ve funkcionálním programování vás za to poplácají po zádech, v objektovém to hodně nerad vidím (obdoba anemického modelu, ale jen s metodami).

Je to defaultní implementace metod rozhraní (v terminologii Swiftu a ObjC protokolů) a v rámci OOP to je nejelegantnější a nejefektivnější způsob řešení zmíněného problému.

Tak já myslím, že termín i význam slova "rozhraní" je dostatečně přímočarý a nezáludný, přičemž v něm nenalézám jakýkoliv náznak implementace. To, co popisujete, vypadá spíše jako trait - že si nějaký jazyk pod "rozhraním" představuje něco jiného, je jeho problém, my bychom se měli bavit v obecné rovině, ne podle toho, jak to kdo kde ubastlil. Takže příště prosím pište rovnou o traitech či mixinech, ušetříme si tím nedorozumění a příspěvky.
Na eleganci a efektivitě jsme se v této diskusi ještě neshodli.

To je slovíčkaření, navíc koncept rozhraní pochází z ObjC, jehož je Swift přímým následovníkem (akorát se tomu říká protokol), takže co může nebo ne být rozhraní celkem logicky určují příslušní tvůrci. Ať už se tomu říká, jak chce, je to v rámci OOP nejelegantnější způsob řešení zmíněného problému (efektivita, přiznávám, závisí na implementaci).

649

Vývoj / Re:Automatické uvolňování paměti v c++

« kdy: 21. 01. 2017, 15:25:01 »

tady je seznam programovacích jazyků, který podporujou CLI/CLR
https://en.wikipedia.org/wiki/List_of_CLI_languages
nevim jestli existuje seznam jazyků co maj (GC). Samozřejmě s (GC) se dělá líp protože
za tebe vyžehlí mnoho tvých chyb. Nemusíš na tim tak úzkostlivě přemejšlet. To je taky důvod proč je Java oblíbenější než native C a C/C++. Mono má verzi .NET takže je možné jej použít jak v C++/CLI tak i v C# tak i ve VisualBasicu. C++/CLI je dnes mrtvý protože "Java,Java,Java" 
A dělají se v něm hlavně wrappery z native C a C/C++ do .NET pro Host-UWP ve Win10.
Velký problém (GC) je, že jaksi zpomaluje chod výsledného algoritmu. Což je ale normální protože
obecně algoritmy napsané v .NET jsou pomalejší až 4x než v např. native C/C++. Výhodou je ale
pohodlnější kodování. Takže se musíš vybrat odpovídající technologii s ohledem na zadání úlohy.
Jádro úlohy můžeš napsat např. v C nebo C/C++ a GUI pak třeba v C# nebo v Javě.

Tady máš ještě pár hezkých článku:
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memory-management-method-of-garbage-collection-like-in-Java

Ne, C++/CLI v Monu použít nejde.

650

Vývoj / Re:Automatické uvolňování paměti v c++

« kdy: 21. 01. 2017, 10:59:05 »

Jestli hledáš C++, které má GarbageCollector (GC) tak je to verze ECMA C++/CLI a je normálně dostupná v MS VS 2003/5/8/10/13/15/17. Native ANSI C++ pochopitelně (GC) nemá. Takže když potřebuješ C++ s (GC) tak si musíš vybrat tu správnou verzi.  Je nutné dodat, že C++/CLI je momentálně ze strany MS nepodporovaný protože má malou komunitu vývojářů a poslední plně
"funkční" verze je v MS VS 2008 C++/CLI SP2.

No jo, to jde ale jen pro řízené objekty (MyOject^) a nejde to přeložit do nativního kódu. A není to multiplatformní, protože implementace je tak zprasená, že Mono nebo VM od MS na Linuxu na tom chcípne.

651

Vývoj / Re:Automatické uvolňování paměti v c++

« kdy: 21. 01. 2017, 03:21:13 »

Btw ARC odmaže navzajem se rušící (++ a -- nad stejnou referencí) reference county ve stejnem scope v době kompilace, takže RC je pak pekelně rychlí i s vice vlakny.

Možná tak u Hello World. V běžném programu je hodně objektů, které se likvidují v jiném scope, než kde vznikly. Kdyby se totiž všechny objekty likvidovaly ve stejném scope, tak vůbec není potřeba alokace na haldě (a nějaké GC) a všechny alokace by šlo vyřešit při kompilaci.

Swift hlavně provádí escape analýzu (podobně jako Go) a co jde, dá na zásobník. U kolekcí je navíc hodnotová sémantika a CoW. U RC se navzájem vyruší release/retain u návratu z funkce a příslušného volání, takže RC se natvrdo mění jen u unikajících referencí, typicky v případě kolekcí.

652

Vývoj / Re:Dědičnost dnes

« kdy: 20. 01. 2017, 15:54:29 »

Jak "rozdělení funkcí do rozhraní" vede ke sdílenému kódu??? Rozhraní z podstaty věci žádný kód neobsahuje.

Triviálně:

Kód: [Vybrat]

protocol Parallelogram { /* declarations of properties */ }
extension Parallelogram {
  var area:Double { return cos(angle) * sideA * sideB }
}

Pokud to jazyk neumožní takto elegantně, tak např. v Go prostě

Kód: [Vybrat]

func Area(p Parallelogram) float64 { return ... }

Důležité je, že se pracuje jen s rozhraním. Jak třídy od sebe dědí je fuk, ostatně v tomto případě by to měly být beztak hodnotové typy, kde dědičnost není vůbec, ale to je už jiný problém.

Pracujete se zmatením pojmů - to, co jste napsal, není rozhraní. Rozhraní je (už z názvu) jen to, co je vidět zvenku, tohleto je jakýsi hybrid zahrnující i implementaci (má to i Java jako rozhraní s default). Ve funkcionálním programování vás za to poplácají po zádech, v objektovém to hodně nerad vidím (obdoba anemického modelu, ale jen s metodami).

Je to defaultní implementace metod rozhraní (v terminologii Swiftu a ObjC protokolů) a v rámci OOP to je nejelegantnější a nejefektivnější způsob řešení zmíněného problému.

653

Vývoj / Re:Dědičnost dnes

« kdy: 20. 01. 2017, 11:44:34 »

[...] Rozhodující je, zda chcete čtverec modelovat pomocí obdélníku, nebo ne. Není důvod, aby to nešlo.
Jedním řešením vámi uvedeným je rozhraní. U jazyků bez podtypového polymorfismu se nepoužívá.
Jak "rozdělení funkcí do rozhraní" vede ke sdílenému kódu??? Rozhraní z podstaty věci žádný kód neobsahuje.

Triviálně:

Kód: [Vybrat]

protocol Parallelogram { /* declarations of properties */ }
extension Parallelogram {
  var area:Double { return cos(angle) * sideA * sideB }
}

Pokud to jazyk neumožní takto elegantně, tak např. v Go prostě

Kód: [Vybrat]

func Area(p Parallelogram) float64 { return ... }

Důležité je, že se pracuje jen s rozhraním. Jak třídy od sebe dědí je fuk, ostatně v tomto případě by to měly být beztak hodnotové typy, kde dědičnost není vůbec, ale to je už jiný problém.

654

Vývoj / Re:Dědičnost dnes

« kdy: 18. 01. 2017, 16:44:28 »

A zase oblíbený problém vejce vs. slepice...
Kolik toho o tom bylo napsáno a kolikrát na tento problém někdo skutečně v praxi narazil? Proč někdo za každou cenu potřebuje vydělovat čtverec od obdélníku do speciální podtřídy? Jen kvůli tomu, že se to nabízí a že to jde? To není dostatečný argument. Vytvářet speciální podtřídy má smysl jedině tehdy, bude-li to k něčemu dobré, tedy ušetří-li se tím někde nějaká práce, či zpřehlední-li se tím něco. Potřebuje-li někdo mermomocí čtverec, může k tomu dobře posloužit speciální konstruktor (či jiný prostředek k výrobě instancí), který prostě vrátí obdélník s a = b.

Tohle je přesně ten moment, kdy mi na OOP vadí, že spoustu lidí tak nějak motivuje k vytváření si dalších problémů, jež zdánlivě přináší objektový návrh, ještě nad rámec těch, které je třeba doopravdy řešit. Programy manipulující s obdélníky a čtverci existovaly dávno před OOP, ale teprve s OOP lidi od počítačů začali meditovat nad tím, co je od čeho odvozené, a ještě se o tom do krve hádat.
I když ono je to podobné jako s makry v Lispu či s definujícími slovy ve Forthu. Obojí také svádí k nadužívání, jakmile člověk pochopí, jak to funguje. Jenže další fází by mělo být taky pochopení, kdy se na to vykašlat a raději použít nějaký méně cool prostředek.

Čtverec je popsán jen jedním číslem a když jich chci uložit do paměti třeba miliardu, tak už je to znát.

655

Vývoj / Re:Dědičnost dnes

« kdy: 18. 01. 2017, 00:25:53 »

Když už jsme u toho dědění, čtverec i obdélník jsou zvláštním případem pravidelného čtyřúhelníku, kde např. plocha se vypočítá jako základna * výška a u obou dochází k tomu, že výška splývá s druhou stranou.

Akorát že čtverec je pod obdélníkem, protože je definován více omezeními - relace být podmnožinou množiny omezení (constraints) je kovariantní k dědičnosti. Viz diagram tady s více typy: https://cs.wikipedia.org/wiki/Čtyřúheln%C3%ADk
To se ale učí už na ZŠ (kde někteří intelektuálně zůstali i v dospělosti), nicméně diskuse se týkala isomorfismu "is a" a dědičnosti v OOP. Dědičnost tak, jak je implementována, je prostě moc svazující.

656

Vývoj / Re:Dědičnost dnes

« kdy: 17. 01. 2017, 21:25:42 »

Psal jsem o tom, že "dědění" dat (proměnných, resp. vlastností) zhusta nedává smysl, např. čtverec IS A obdélník, ale obdélník se popisuje dvěma čísly, kdežto čtverec jen jedním.

To mas sice pravdu, ale to je spis tim, ze dedeni proste neresi dobre vsechny druhy IS-A vztahu. Kazdopadne, moje pointa byla, ze tridy smesuji tri ruzne koncepty, jestli jednomu z nich rikame dedeni nebo nejak jinak neni az tak podstatne. Jinak dedeni dat se taky pouziva v relacnich databazich, takze to jde i bez polymorfismu.

Jo, je to trochu mimoběžná poznámka, ale vždy se hodí připomenout, že klasická dědičnost, tak jak je v OOP, je poněkud záludná, protože vždy se najde blb, co je schopen tvrdit, že "Rectangle extends Square".

657

Vývoj / Re:Dědičnost dnes

« kdy: 17. 01. 2017, 18:13:20 »

Naopak dědičnost dává smysl pro funkce, u dat to často skřípe.

To si nerozumime. Ale jelikoz tvuj komentar nema moc obsahu, tezko rict v cem. Mozna proto, ze chapes slovo dedicnost prilis uzce, prave jen v souvislosti s tridami.

Treba jazyk Go ma take ty tri koncepty rozdelene, a dedeni dat (a jen dat!) tam jde delat pomoci vnorene struktury, zatimco na polymorfismus slouzi interfaces.

Možná je to nedorozumění. Psal jsem o tom, že "dědění" dat (proměnných, resp. vlastností) zhusta nedává smysl, např. čtverec IS A obdélník, ale obdélník se popisuje dvěma čísly, kdežto čtverec jen jedním. Veškeré operace typické pro obdélník ale fungují stejně, akorát obdélník má všechny strany stejně velké, což je ovšem funkcím putna. Jinými slovy když řeknu "Square extends Rectangle", tak čtverec najednou bude mít taky dvě proměnné, což je špatně, protože redundance, neelegance atd. A tento problém žádné přímočaré řešení nemá (aspoň v současných jazycích), ledaže člověk funkce rozčlení do rozhraní, což se právě čím dál více rozmáhá. Pak dědičnost jako taková zmizí, ale zůstane sdílený kód a stejná množina relevantních proměnných, byť implementovaných různě. V konečném důsledku pak mám, co chci, zejména polymorfismus a sizeof(square) = sizeof(rectangle) / 2.

658

Vývoj / Re:Dědičnost dnes

« kdy: 17. 01. 2017, 17:08:41 »

Puvodni Karel ma pravdu - OOP (jak se bezne chape, treba v Jave) micha tri koncepty dohromady (zapouzdreni, dedicnost, polymorfismus) do jednoho - trid. Je to omyl a zpetne to vidime. Konkretne, dedicnost dava smysl pro data, nikoli pro funkce, a naopak, polymorfismus dava smysl pro funkce, nikoli pro data. A potreba neco zapouzdrit jeste neznamena, ze musime vytvaret novy typ.

Treba Haskell (jako vetsina funkcionalnich jazyku) to ma rozdelene pomerne jasne. Zapouzdreni se realizuje pomoci modulu, dedicnost pomoci treba algebraickych typu (nebo obecne typu vyssiho radu) a polymorfismus pomoci typovych parametru a typovych trid.

Naopak dědičnost dává smysl pro funkce, u dat to často skřípe.

659

Vývoj / Re:Dědičnost dnes

« kdy: 17. 01. 2017, 15:06:35 »

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? Stále narážím na lidi, kteří milují dědičnost a používají ji třeba i na to, aby kód neměli duplicitní. Chápu ještě využití polymorfismu, ale to není až tak časté. Ale celkově to moc dnes nedává smysl, tak jsem chěl vědět názory zdejších odborníků. Třeba Kit by mohl něco zajímavého přinést.

Někoho by mohlo v této souvislosti zajímat "protocol-oriented programming", což je velmi zajímavé a hlavně efektivní paradigma. V některých jazycích (např. Go) je v podstatě vynucováno a v jiných, které podporují přímo v syntaxi i OOP, umožňuje elegantnější (a lépe udržovatelný) zápis kódu. Navíc na rozdíl od OOP se dá dobře kombinovat s FP.

660

Vývoj / Re:Dědičnost dnes

« kdy: 17. 01. 2017, 15:01:04 »

False.
OOP je o komunikačním grafu agentů.
Dědičnost je víceméně z nouze ctnost.
OOP prostě nejde ke statickému typování.

Agenty jako (chytré) instance nesouvisejí s konstrukcí tříd pro výrobu (hloupých) instancí.
Dědičnost je mechanismus pro odvozování podobných tříd.
Původní OOP nikdy statické nebylo, to vzniklo až jako hybridní, původně imperativní jazyky. Z toho jsou pak mylně odvozovány obecné vlastnosti OOP.

To původní bylo vlastně velmi jednoduché, jen zprávy mezi objekty, bez ohledu na dědičnost. Celá ta současná diskuse o Javě apod. je pak dost zcestná a není ani tak o OOP, jako o omezeních imperetivních jazyků, na které byly naroubovány objekty a virtuální volání.