Dědičnost dnes

[gll]

Sorry, já nějak ztrácím přehled, co se snažíte dokázat.

teď jsem se jen snažil popsat, o jaké immutable reprezentaci jsem předtím mluvil. Protože jste mě špatně pochopil. Nic už se dokázat nesnažím.

[Reklama]

[SB]

Stejná otázka jako pro gil: co se komu snažíte dokázat nebo co vyvrátit?

Jednoduchost implementace grafu v OOP?

[Mirek Prýmek]

Jednoduchost implementace grafu v OOP?

A z toho má plynout co?

[lopata]

V tom případě to děláte špatně, protože za předpokladu, že si tam můžete vnést libovolné omezující podmínky, existuje daleko jednodušší argument:

Vyhldávání se složitostí O(1) existuje:

Kód: [Vybrat]

def search(_,_), do: nil
...ovšem za předpokladu, že se bavíme jenom o prázdných seznamech.

Omezující podmínka prakticky vždy existujie, je to např. datový typ. Tohle je O(1):

Kód: [Vybrat]

class Set {
public:
    void set(const uint32_t value) {
        bitset[value] = true;
    }

    bool get(const uint32_t value) const {
        return bitset[value];
    }

private:
    std::bitset<std::numeric_limits<uint32_t>::max() + 1ULL> bitset;
};


[Mirek Prýmek]

Omezující podmínka prakticky vždy existujie, je to např. datový typ.

Jenže ten datový typ může být (a v našem obecném povídání je) nekonečný.

[Reklama]

[lopata]

Jenže ten datový typ může být (a v našem obecném povídání je) nekonečný.

Bez omezujících podmínek nelze vyrobit žádné hledání. Pouze za předpokladu, že je k dipozici nekonečná paměť.

[Mirek Prýmek]

Bez omezujících podmínek nelze vyrobit žádné hledání. Pouze za předpokladu, že je k dipozici nekonečná paměť.

Jasně. Takže když chci hledat v množině příjmení, tak to s O(1) jde, akorát na to potřebuju nějakých 24^max_len bitů pole.

Tak jo, tak jsme si zablbli a už toho necháme, ne?

[BoneFlute]

Takze vezmime si konfiguraciu aplikacie, ktora sa kazdych x minut obnovuje. A budem mat 50 nekonzistentnych konfiguracnych objektov, lebo pan riesi Http request a filesystem. Alebo spravi sa singleton a budem mat konfiguraciu na jednom mieste, pre vsetkych rovnaku.

Dalsi priklad mam rozhranie rs232, tam nie je httprequest alebo databaza, problem je vsak, ze je len jedno. Bud vymyslim neviem ake zamykanie cez 50 instancii, alebo si proste spravim singleton.

Potrebujem nieco serializovat von do nejakeho mrdkoveho suboru, co nema http request ani databazu, a je potrebne aby sa do neho nezapisovalo z 50 miest. Takze bud spravim sialene zamykanie cez 50 instancii, alebo spravim singleton. Pripadne sa zahram na to, ze som jouda a singleton nepoznam a ten isty objekt odovzdavam vo vsetkych metodach. To je potom "super", zbytocne to tam zavadzia.

Dalsi relevantny pripad. Chcem sa vyhnut "statickej" triede, lebo je to vlastne zkripleny objekt a ja chcem normalny, pouzijem singleton.

Ked robim webku pre jouda sro v php, mozno singletony nie su treba. Ale pri roznych IRL aplikaciach potreba nastava. U vas toho polku zariadi webserver a ani o tom neviete.  Ja osobne, kde mozem, pouzijem framework, co sa o instancie stara za mna. Ale su pripady, ked nemozem, lebo kodim zrovna lib-ku, co ma mat zavislost iba na java api. Tam singleton vyuzijem.

Tak to jsou zrovna hodně špatné příklady - to, že potřebujete číst jedinou konfiguraci, používat jedno spojení a komunikovat přes jeden sériák, neznamená, že je musíte vyrobit jako jedináčka. Objekt, který s nimi pracuje, je má dostat při inicializaci nebo spuštění akce (nebo od někoho, koho zná). Co se stane, když budete mít více konfiguráků? Když přidáte další sériák? Když budete komunikovat s 3 servery?
Toto řešení mi spíš zavání globálními odkazy přes třídu. Antivzor znemožňující testování, zvyšující coupling a zabordelující aplikaci!

Že nejdou třídní věci dát do třídy, protože je Java zprasená, je věcí druhou.

To je toho prskania, musel som si ocistit macbook. Ked budem potrebovat 3 seriaky, odstranim singleton z objektu a spravim si pool. A zrovna ten pool bude tiez singleton. To da kurevsku praci zmazat tri riadky. A ze je globalny objekt pre aplikaciu, ano je, o tom je, to je feature.

Musim ocenit, ze viete googlit ale:

• Nevola sa to triedne, ale objektovo-orientovane programovanie. Je to objektoch, triedy nestastne vymyslel Kay.
• Testovanie singleton neztazuje, staci si nastavit pri testovani singleton. Skobinujem ho so vzorom strategy a voila, da sa to menit za hocico! Brutalne tazka robota. Rozne mock objekty a  netrivialne zavislosti testovanie komplikuju viac. Btw unit testy ako su dnes vymyslene nie su objektove.
• Viac konfigurakov v jednej aplikacii? To je naco dobre?

Ale jo, mi ti to neberem. Taky jsem to tak dělal. Pak jsem přišel na to, že to není dobrý nápad. To je prostě všechno.

[lopata]

Jasně. Takže když chci hledat v množině příjmení, tak to s O(1) jde, akorát na to potřebuju nějakých 24^max_len bitů pole.

Tak jo, tak jsme si zablbli a už toho necháme, ne?

Nepotřebuju tak velké pole, pokud vím, že příjmení bude maximálně N, můžu v konečném čase vyrobit perfektní hashovací funkci, která bude přijmení mapovat na číslo v intervalu 0..N-1 plus mínus autobus.

Pokud nevím, že bude příjmení maximálně N, nemůžu garantovat nic, protože nekonečnou paměť nemám k dispozici. Praktická omezující podmínka téměř vždy existuje. Hledání s maximální složitostí O(1) se bežně dělá, pokud je to potřeba.

[BoneFlute]

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. Ked programujem funkcionalne pripadam si ako matfyzak, ktory zo seba suka definicie. Nie ako bezny clovek, co si povie, ze teraz spravim toto a potom hento ...  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

A nebo prostě trvá, než si na to lidi zvyknou.

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

[balki]

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. Ked programujem funkcionalne pripadam si ako matfyzak, ktory zo seba suka definicie. Nie ako bezny clovek, co si povie, ze teraz spravim toto a potom hento ...  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

A nebo prostě trvá, než si na to lidi zvyknou.

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

[BoneFlute]

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. Ked programujem funkcionalne pripadam si ako matfyzak, ktory zo seba suka definicie. Nie ako bezny clovek, co si povie, ze teraz spravim toto a potom hento ...  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

A nebo prostě trvá, než si na to lidi zvyknou.

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

To už je jiné téma.

[Inkvizitor]

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

A co z toho plyne?

[balki]

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

A co z toho plyne?

Ze pokial prejdeme od skolskych prikladov do realneho sveta, multiparadigmovitost je vsadepritomna.

[Inkvizitor]

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

A co z toho plyne?

Ze pokial prejdeme od skolskych prikladov do realneho sveta, multiparadigmovitost je vsadepritomna.

To jsi jenom jinymi slovy opsal to, co jsi tvrdil predtim. Otazka zni, zda ta "multiparadigmaticnost" je zadouci nebo je to provizorni stav. Jestli bude deklarativniho kodu pribyvat nebo ubyvat a jak se bude vyvijet vzajemna interakce deklarativni a imperativni casti programu. A jestli by to uz ted vlastne neslo delat lip.