Příspěvky

1351

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 17:24:44 »

Tady ale směšuješ dvě různé věci. Defaultní metody v Javě slouží jednak k omezené vícenásobné dědičnosti a jednak k tomu, aby bylo možné bezpečně rozšiřovat interfacy, které jsou součástí veřejných API. Druhý bod byl Oraclem prezentován jako jejich hlavní selling point, tzn. že defaultní metody jim umožnili rozšířit do té doby zamrzlé API kolekcí. Sranda je to, že nakonec k tomu prakticky vůbec nedošlo a veškeré funkcionální operace se místo kolekcí dostaly do nového typu - streamů.

Extension metody v C# naproti tomu slouží k rozšiřování tříd, nad kterými nemám kontrolu (jsou součástí SDK, knihoven atd.) a to v Javě dodnes není možné. Proto např. Guava definuje spoustu statických tříd pojmenovaných plurálem třídy, nad kterou operují (Strings, Ints, Iterables, Lists atd.). Takže pak můžu dělat toto: Lists.filter(list, predicate), ale už ne tohle: list.filter(predicate).

Jenže v C# to jde i pro rozhraní.

1352

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 16:20:34 »

https://developer.apple.com/videos/wwdc/2015/?id=408

Když uz jsme u toho, nevíte někdo, proč v C# udělali tak debilně extension methods v cizích statických třídách?

A v čem je to debilní, resp. jak by to mělo být?

Má to být přímo v tom rozhraní, jako v Javě.

1353

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 14:59:04 »

https://developer.apple.com/videos/wwdc/2015/?id=408

Když uz jsme u toho, nevíte někdo, proč v C# udělali tak debilně extension methods v cizích statických třídách? Java to má aspoň pohromadě.

1354

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 14:24:17 »

P.S. s/praktik/lepič

Nemusí to být lepič. Stačí aby se s něčím setkal poprvé. Ona ta elegance na první pohled vidět není. Je třeba začít o problému uvažovat trochu jinak.

Jo, to je pravda. Mně jen vadí, když někdo kritizuje něco, než se s tím seznámí.

1355

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 14:08:57 »

Z PDF se zdá jako že by protokoly snad měly být lepší náhrada za běžné OOP a to není pravda.

Je to pravda. Častý problém programátorů-praktiků je, že jako "lepší" si představují to, co má víc čudlíků, hejblátek, generuje to víc kódu apod. Viz např. "můj jazyk je lepší, protože se v něm dá dělat i x" (hurá, "multiparadigmatický jazyk"). Ve skutečnosti je to ale spíš opačně - čím je věc omezenější, tím tam platí silnější předpoklady a tím se mj. dá i líp optimalizovat. A často je taky v důsledku obecnější, protože stačí splnit pevné předpoklady a platí spousta důsledků.

Protokoly jsou k tomu, aby se ke všem věcem, které splňují nějaké předpoklady, dalo chovat stejným způsobem. Podobně jako v OOP když mají společného předka. Akorát u protokolů nemusíš třešit tragikomické důsledky hierarchizace dědičnosti. Prostě to kváká jako kachna, tak je to kachna. Co víc chtít?!

Aneb Einsteinovo "Everything Should Be Made as Simple as Possible, But Not Simpler".

P.S. s/praktik/lepič

1356

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 14:02:18 »

Protokol je původní název pro tento koncept. Dědičnost protokolů tam je. Virtuální metody ("defaultní") tam jsou taky. Někdo má problémy s porozuměním jednoduchému textu...

Z PDF se zdá jako že by protokoly snad měly být lepší náhrada za běžné OOP a to není pravda.
Vím že ve Swiftu jsou i class a ty fungují "postaru". Stejně tak "postaru" ve Swiftu dělají přepsání virtuální metody v potomku.

Specializace protokolu je většinou lepší než odvození z nadtřídy. Viz příklad někde výše, kde čtverec dědí z rovnoběžníku. V "běžném" OOP nejde v žádném jazyce mít společnou metodu pro výpočet obsahu a přitom méně atributů u čtverce. Principiálně tomu sice nic nebrání, ale v C++, C#, ObjC ani Javě to prostě nejde.

1357

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 13:58:10 »

Mě jako haskellistu by moc zajímali podrobnosti. Nemáš nějaký pěkný pokec o tom? Nebo to tu alespoň trochu rozveď.

Taky by me to zajimalo.. zkousel jsem to vygooglit ale nic jsem nenasel.

Já Haskell moc neznám. Zde je explicitně zmíněn:

https://en.m.wikipedia.org/wiki/Protocol_(object-oriented_programming)
https://mobile.twitter.com/bos31337/status/473545340864700416
https://bigonotetaking.wordpress.com/2015/07/17/swift-protocols-a-strategy/

1358

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 13:37:06 »

Aby tu nebylo jen pusté filosofování, zde je "protocol-oriented" kód (ať to není příliš dlouhé, tak jen pro nejobecnější a nejspeciálnější případ):

Kód: [Vybrat]

protocol QuadrilateralWithParallelOppositeSides {
    var side1:Double { get }
    var side2:Double { get }
    var skew:Double { get }
}

extension QuadrilateralWithParallelOppositeSides {
    func area() -> Double {
        return side1 * side2 * cos(skew)
    }
}

struct Parallelogram : QuadrilateralWithParallelOppositeSides {
    var side1:Double
    var side2:Double
    var skew:Double
    init(side1 s1:Double, side2 s2:Double, skew s:Double) {
        side1 = s1
        side2 = s2
        skew = s
    }
}

struct Square : QuadrilateralWithParallelOppositeSides {
    var side1:Double
    var side2:Double { return side1 }
    var skew:Double { return 0 }
    init(side s1:Double) {
        side1 = s1
    }
}

let figure1 = Parallelogram(side1: 2, side2: 3, skew: M_PI_4)
let figure2 = Square(side: 3)
var list:Array<QuadrilateralWithParallelOppositeSides> = [ figure1, figure2 ]
print(list.map { $0.area() })

Jak je hezky vidět, metoda pro výpočet obsahu se definuje jen jednou. O různé invarianty se postarají "computed properties". Jednoduché, elegantní a rozšiřitelné

Doplnění k tomuto evidentně nejlepšímu řešení: Ve Swiftu je pro čtverec ona generická metoda stejně rychlá jako side1*side1 (agresivní optimalizace). V C++ clang generickou metodu také optimalizuje, ale zrychlení není o řád. Microsoftí C++ neoptimalizuje nic. C# zrychlí defaultní metodu asi o polovinu a Java (osmička) 4-5x. Sečteno a podtrženo: Swift jasně vede (v implementaci), ale kromě Microsoftího C++ si mainstream s optimalizací generické metody pro výpočet obsahu rovnoběžníku hravě poradí.

1359

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 11:57:44 »

https://developer.apple.com/videos/wwdc/2015/?id=408

vypadá to jako Type Classes z Haskellu (které jsou prý nic proti Modules z OCamlu) nebo se mi to zdá?

Nezdá

1360

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 11:57:08 »

https://developer.apple.com/videos/wwdc/2015/?id=408

Nejsou virtuální metody, není dědičnost, jsou jenom interface pod novým názvem protokol. Objektivně je to tedy méně hodnotné než OOP a na funkcionalitu virtuálních metod, tedy starý kód může volat nový, se vykašlali úplně.

Protokol je původní název pro tento koncept. Dědičnost protokolů tam je. Virtuální metody ("defaultní") tam jsou taky. Někdo má problémy s porozuměním jednoduchému textu...

1361

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 10:41:21 »

https://developer.apple.com/videos/wwdc/2015/?id=408

^ FF i Chrome. Vidim, ze v ovocne firme opravdu jedou na UX.

Stačí to PDF

1362

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 10:07:43 »

https://developer.apple.com/videos/wwdc/2015/?id=408

1363

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 15. 09. 2015, 15:58:54 »

Ano, ale to je imperativní programování, díky neznámým závislostem mezi objekty nelze automatizovaně výpočet paralelizovat a dokazovat, což FP by mělo umožňovat. Ten if je samozřejmě extrém, ale na něm se ukáže, zda myslíte funkcionálně, či imperativně. Funkcionální programování vyžaduje oprostit se od pojmu čas, a tedy vás to osvobodí do jisté míry, od nutnosti zabývat se pořadím zpracování, výsledek matematické funkce závisí jen na vstupních hodnotách, nikoliv na pořadí zpracování funkcí ...

A to by mě teda docela zajímalo.

První námitka: Podle mě můžu definovat trojici {a,b,c}, která odpovídá ifu. Takže máme ten kýžený výběr z trojic. Pokud to tak nejde, chtěl bych vidět nějakou pořádnou argumentaci.

Co jsou "neznámé závislosti", nevím. Pořadí vyhodnocení můžu u ifu měnit jako u jakékoliv jiné fce.

No ten if byl extrém. Jak si ho vizualizujete, když programujete? Jako porovnání konkrétních hodnot, předpokládám, tedy imperativním způsobem myšlení.

If je normální matematická funkce, nejjednodušším příkladem je třeba |x|.

1364

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 14:29:10 »

Jak uz od zacatku tady nekdo rikal, vsechno zavisi na zpusobu pouziti.
Tyhle zobecnovani, co tady delas zas vedou tomu, ze casto to co kompl zvladl pred 20 lety s tehdejsim hw, dela dneska na 20 let novejsim hw stejnou dobu. Kdyz budes mit miliardy ctvercu a budes je nekde muset skladovat a budes potrebovat pocitat jejich obsahy, tak si sakra rozmyslis, jestli tam budes nekde pocitat cos, drzet si zbytecne data, atp.

Já znám protokoly primárně z Haskellu. Nevím jak jinde ale v Haskellu tu potřebnou tabulku funkcí hlídá a předává překladač. A taky ty funkce ochotně inlinuje všude, kde to jenom jde. Takže pokud budu mít miliardy čtverců a budu si jistý tím že to jsou čtverce, tak mi překladač zainlinuje volání a kosinus vyoptimalizuje pryč.

Zrovna protokoly jsou abstrakce, která umí být překvapivě levná. Teda aspoň v příčetně navrženém jazyce.

Ha, tak Swift se zdá být naprosto příčetný, pro Array<Square> je zrychlení výpočtu skoro o dva řády.

1365

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 12:54:06 »

Ty dvě počítané vlastnosti jsou tam zcela zbytečné. A co je zbytečné, musí pryč.

Ty počítané vlastnosti rozhodně nejsou zbytečné. Slouží k tomu aby šel čtverec použít všude tam, kde se dá použít rovnoběžník. Pokud mám třeba funkci na kreslení rovnoběžníka, tak pokud má čtverec tyhle dvě "zbytečné" vlastnosti tak ho tímhle způsobem můžu nakreslit taky.

Nebo chci přidat funkci pro obvod. Ve tvém případě musím tu funkci dodat do interface a doimplementovat ve všech odvozených třídách. Není jednodušší napsat jedinou funkci, která spočítá obvod rovnoběžníka a v případě čtverce využívá ty "zbytečné" počítané vlastnosti?

Jak uz od zacatku tady nekdo rikal, vsechno zavisi na zpusobu pouziti.
Tyhle zobecnovani, co tady delas zas vedou tomu, ze casto to co kompl zvladl pred 20 lety s tehdejsim hw, dela dneska na 20 let novejsim hw stejnou dobu. Kdyz budes mit miliardy ctvercu a budes je nekde muset skladovat a budes potrebovat pocitat jejich obsahy, tak si sakra rozmyslis, jestli tam budes nekde pocitat cos, drzet si zbytecne data, atp.

Odtud pak vznikaji napriklad tragicke aplikace v Jave - nepouzitelny lagovaci moloch, prestoze Java sama o sobe umi byt i relativne hodne rychla.

P.S. sizeof(Parallelogram) = strideof(Parallelogram) = 24 a světe div se, sizeof(Square) = strideof(Square) = 8