Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: phpmág 15. 01. 2017, 17:52:24

Název: Dědičnost dnes
Přispěvatel: phpmág 15. 01. 2017, 17:52:24
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ázev: Re:Dědičnost dnes
Přispěvatel: Lemming 15. 01. 2017, 18:18:12
Nevím jak ty, ale já dělám architekturu programu tak aby dobře fungoval. Ne podle toho, co je zrovna v módě. Takže větu "Ale celkově to moc dnes nedává smysl..." nechápu.

Samozřejmě, i dědičnost se dá "zneužívat" a zpřístupňovat pomocí ní funkce, které by měly být spíš v utility class, ale to nic nemění na tom, že v některých patternech je velmi užitečná.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 15. 01. 2017, 18:28:36
Tak jsem to nemyslel. Prostě třeba před 20 lety to bylo celkem cool a dost se to používalo. Dnes se ví, že dědičnost je spíše zlo, tak jsem chtěl vědět, jestli pro ní někdo nemá nějaké nové a dobré využítí. A jak moc se používá u kolegů. Máme plno nových jazyků a přístupů, takže všechno se dost mění.

Utility class je také zlo, ne? Tak jasný, v patternech je jí plno, ale je otázkou, jestli jsou ty patterny dnes dobré.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 15. 01. 2017, 18:33:55
Prosím o jeden konkrétní příklad, kdy ta dědičnost nedává smysl,
díky.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 15. 01. 2017, 18:43:24
Třeba pro tu neduplikaci kódu. Dědičnost s tím nemá nic společného, ale lidi to používají jako takovou "úložnu" kódu :D
Název: Re:Dědičnost dnes
Přispěvatel: Honza 15. 01. 2017, 18:50:30
Třeba pro tu neduplikaci kódu. Dědičnost s tím nemá nic společného, ale lidi to používají jako takovou "úložnu" kódu :D
to přece není konkrétní příklad... ukaž kód, nebo link na něj
Název: Re:Dědičnost dnes
Přispěvatel: gll 15. 01. 2017, 18:55:18
Problém je používání pevných typů namísto rozhraní. K tomu dědičnost svádí.
Název: Re:Dědičnost dnes
Přispěvatel: anonym 15. 01. 2017, 18:59:29
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.

Jestli používáš OOP a nepoužíváš dědičnost, tak tvoje znalost OOP busí být opravdu bídná.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 15. 01. 2017, 19:03:53
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é. [...]
V některých jazycích je dědičnost takové "nutné zlo", ale dá se jí vyhnout (a je to žádoucí), viz např. Go. Pokud někdo "miluje" dědičnost, není moc dobrý vývojář.
Např. v Javě jsou knihovny dost mizerně navržené, takže se všude dědí, naopak např. v ObjC (Cocoa) se používají převážně rozhraní a shluky tříd, což je mnohem lepší v mnoha ohledech (dědičnost je jen u tříd pro GUI a měnitelných kolekcích).
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 15. 01. 2017, 19:06:19
Super, alespoň někdo to chápe. Přesně tak, pokud se bavím s někým, kdo ji má rád, tak obvykle zjistím, že vůbec nerozumí designu. Pak ten kód samozřejmě nejde číst a nedává smysl.

Co tedy navrhuješ pro duplicity? V Javě by to šlo třeba přes generika, ale to Go nemá? Teď nevím, moc ho neznám.
Název: Re:Dědičnost dnes
Přispěvatel: Kit 15. 01. 2017, 19:13:31
Dědičnost používám tam, kde se potřeba. Je nutné, aby byl splněn výrok "potomek" _je_ "rodič". Například Automobil je Vozidlo, Faktura je Doklad, Kvádr je Těleso apod. Zároveň musí být v programu možná zaměnitelnost potomka a rodiče. Pokud tato pravidla nejsou splněna, dědičnost nelze použít.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 15. 01. 2017, 19:20:24
Super, alespoň někdo to chápe. Přesně tak, pokud se bavím s někým, kdo ji má rád, tak obvykle zjistím, že vůbec nerozumí designu. Pak ten kód samozřejmě nejde číst a nedává smysl.

Co tedy navrhuješ pro duplicity? V Javě by to šlo třeba přes generika, ale to Go nemá? Teď nevím, moc ho neznám.

Defaultní implementace u rozhraní. Go to ale nemá, musí se řešit funkcemi. Ono Go je obecně relativně low-level a hodně věcí tam elegantně napsat nejde.
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 07:37:57
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.

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak :)

Dedicnost pouzivam vtedy, ked potrebujem pouzit polymorfizmus. Alebo ked mam niekolko objektov, ktore maju mat navonok rovnake spravanie a mozu byt lubovolne zamenitelne. (slovo objekt pouzivam zamerne, na dualizmus trieda-instancia sa moc nehram). Vyhybam sa hlbokym hierarchiam dedicnosti, ak nie som nuteny (napriklad nejakym frameworkom).

Dedicnost, je ozaj sikovna vec, len to netreba cpat vsade za kazdu cenu.
Název: Re:Dědičnost dnes
Přispěvatel: jpu 16. 01. 2017, 07:58:06
ak vynechame dedicnost, tak potom ako mozme rozpravat o OOP? Predsa dedicnost patri medzi zakladne prvky objektovo-orientovaneho vyvoja. To, ze to modne trendy pouzivaju, nemusi hned platit, ze to je aj spravne.
Název: Re:Dědičnost dnes
Přispěvatel: Kamil Podlešák 16. 01. 2017, 08:14:17
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.

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak :)
Já bych nebyl tak striktní - použití dědičnosti pro odstranění duplicity je v mnoha jazycích s tradičním OOP osmdesátých/devadesátých let (třeba Java) celkem v pohodě. Ale jenom pokud se jedná o čistě implementační záležitost (ideálně ani společný předek není veřejný). Problémy nastanou pokud někdo použije dědičnost jako součást API. To prakticky vždy znamená jámu do které někdo spadne...

Dedicnost pouzivam vtedy, ked potrebujem pouzit polymorfizmus.
Jenom pro úplnost: jsou jazyky kde je možný polymorfismus i bez dědičnosti.
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 08:32:38
Já bych nebyl tak striktní - použití dědičnosti pro odstranění duplicity je v mnoha jazycích s tradičním OOP osmdesátých/devadesátých let (třeba Java) celkem v pohodě. Ale jenom pokud se jedná o čistě implementační záležitost (ideálně ani společný předek není veřejný). Problémy nastanou pokud někdo použije dědičnost jako součást API. To prakticky vždy znamená jámu do které někdo spadne...

Ved prave, v jave je vela takychto uchylakov, co to robia. Bud presli z MVC++, alebo mali nejakeho nevzdelaneho ucitela.  Osobne riesim duplicitu kodu bud delegaciou, alebo worker objectom, teraz k tomu pribudli aj funkcie. (No vo funkciach nie som este celkom doma). U mojho prveho zamestnavatela (nastastie som vtedy ako javista nepracoval), ked niekto pouzil dedicnost, aby sa mu neopakoval kod, dostal polhodinoveho "zjeba", ze ako si to predstavuje takto hovnit :)
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 08:38:56
Dedicnost pouzivam vtedy, ked potrebujem pouzit polymorfizmus.
Jenom pro úplnost: jsou jazyky kde je možný polymorfismus i bez dědičnosti.

Pri duck typingu sa pouziva dedenie spravania. Nepouziva sa tam sice explicitny "interface", ako v jave. Ale programator skratka vie, ze ten objekt ma nejake rozhranie (metodu). (alebo sa skratka spyta, ci taku ma)
Název: Re:Dědičnost dnes
Přispěvatel: gll 16. 01. 2017, 08:42:09
Já bych nebyl tak striktní - použití dědičnosti pro odstranění duplicity je v mnoha jazycích s tradičním OOP osmdesátých/devadesátých let (třeba Java) celkem v pohodě. Ale jenom pokud se jedná o čistě implementační záležitost (ideálně ani společný předek není veřejný). Problémy nastanou pokud někdo použije dědičnost jako součást API. To prakticky vždy znamená jámu do které někdo spadne...

Ved prave, v jave je vela takychto uchylakov, co to robia. Bud presli z MVC++, alebo mali nejakeho nevzdelaneho ucitela.  Osobne riesim duplicitu kodu bud delegaciou, alebo worker objectom, teraz k tomu pribudli aj funkcie. (No vo funkciach nie som este celkom doma). U mojho prveho zamestnavatela (nastastie som vtedy ako javista nepracoval), ked niekto pouzil dedicnost, aby sa mu neopakoval kod, dostal polhodinoveho "zjeba", ze ako si to predstavuje takto hovnit :)

Jako vždy, označujete všechny za úchyláky, ale nenapíšete racionální důvod, proč to co dělají je špatně.
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 08:47:17
U mojho prveho zamestnavatela (nastastie som vtedy ako javista nepracoval), ked niekto pouzil dedicnost, aby sa mu neopakoval kod, dostal polhodinoveho "zjeba", ze ako si to predstavuje takto hovnit :)

A to jako proč? Co to znamená, "ked niekto pouzil dedicnost, aby sa mu neopakoval kod"? Použití dědičnosti zpravidla redukuje opakování kódu, i když to není primárním účelem.
Název: Re:Dědičnost dnes
Přispěvatel: jpu 16. 01. 2017, 08:51:37
zaujimavy komentar:
http://stackoverflow.com/questions/3351666/why-use-inheritance-at-all (http://stackoverflow.com/questions/3351666/why-use-inheritance-at-all)
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 08:55:22
Já bych nebyl tak striktní - použití dědičnosti pro odstranění duplicity je v mnoha jazycích s tradičním OOP osmdesátých/devadesátých let (třeba Java) celkem v pohodě. Ale jenom pokud se jedná o čistě implementační záležitost (ideálně ani společný předek není veřejný). Problémy nastanou pokud někdo použije dědičnost jako součást API. To prakticky vždy znamená jámu do které někdo spadne...

Ved prave, v jave je vela takychto uchylakov, co to robia. Bud presli z MVC++, alebo mali nejakeho nevzdelaneho ucitela.  Osobne riesim duplicitu kodu bud delegaciou, alebo worker objectom, teraz k tomu pribudli aj funkcie. (No vo funkciach nie som este celkom doma). U mojho prveho zamestnavatela (nastastie som vtedy ako javista nepracoval), ked niekto pouzil dedicnost, aby sa mu neopakoval kod, dostal polhodinoveho "zjeba", ze ako si to predstavuje takto hovnit :)

Jako vždy, označujete všechny za úchyláky, ale nenapíšete racionální důvod, proč to co dělají je špatně.

Podporuje to vznik roznych zkriplenych objektov, ktorych ucel nie je jasny, plus si tym programator zbytocne zahlcuje hierarchiu dedicnosti.

Ked sa pouzije casting potomka na rodica, mal by tento casting v ramci polymorfizmu fungovat. Pri DRY objektoch tomu tak nebyva.
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 09:01:02
Podporuje to vznik roznych zkriplenych objektov, ktorych ucel nie je jasny, plus si tym programator zbytocne zahlcuje hierarchiu dedicnosti.

Ked sa pouzije casting potomka na rodica, mal by tento casting v ramci polymorfizmu fungovat. Pri DRY objektoch tomu tak nebyva.

Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?
Název: Re:Dědičnost dnes
Přispěvatel: Kamil Podlešák 16. 01. 2017, 09:04:00
Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?
Já bych to řekl takhle: když někdo umí používat dědičnost, tak ji používá málo.
Když někdo používá dědičnost často, tak ji nejspíš používat neumí.

Ale pravdu bych se vyhnul ideologickým poučkám "dědičnost nepoužíváme, protože je to prasárna" - vždy je důležité hlavně vědět jaké konkrétní problémy vznikají.
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 09:07:06
U mojho prveho zamestnavatela (nastastie som vtedy ako javista nepracoval), ked niekto pouzil dedicnost, aby sa mu neopakoval kod, dostal polhodinoveho "zjeba", ze ako si to predstavuje takto hovnit :)

A to jako proč? Co to znamená, "ked niekto pouzil dedicnost, aby sa mu neopakoval kod"? Použití dědičnosti zpravidla redukuje opakování kódu, i když to není primárním účelem.

To, ze dedicnost redukuje opakovanie kodu je niekedy zhoda okolnosti, nie primarny ucel.
Ak dava zmysel aj rodic, aj potomok, nekomplikuje to vyvoj potomkov a redukuje to duplicitu kodu, vtedy je to vporiadku.
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 09:09:22
Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?
Já bych to řekl takhle: když někdo umí používat dědičnost, tak ji používá málo.
Když někdo používá dědičnost často, tak ji nejspíš používat neumí.

Ale pravdu bych se vyhnul ideologickým poučkám "dědičnost nepoužíváme, protože je to prasárna" - vždy je důležité hlavně vědět jaké konkrétní problémy vznikají.

Tak to jsou Javisté na tom skutečně špatně, neboť používají dědičnost v každé třídě.
Název: Re:Dědičnost dnes
Přispěvatel: n 16. 01. 2017, 09:11:17
Dědičnost používám tam, kde se potřeba. Je nutné, aby byl splněn výrok "potomek" _je_ "rodič". Například Automobil je Vozidlo, Faktura je Doklad, Kvádr je Těleso apod. Zároveň musí být v programu možná zaměnitelnost potomka a rodiče. Pokud tato pravidla nejsou splněna, dědičnost nelze použít.

Obvykle s Kitem nesouhlasim, ale tentokrat je jediny, kdo to tady minimalne jako Short Answer napsal poradne.
V posledni dobe je zas modni plivat na dedicnost, protoze programatora dela dnes kazdy debil, ktery to neumi pouzivat a pak se dostava do problemu. Casem to prejde - to jsou vzdy takove modni vlny, ktere rostou umerne tomu, kolik amateru ma moznost se k veci vyjadrovat.
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 09:11:34
Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?
Já bych to řekl takhle: když někdo umí používat dědičnost, tak ji používá málo.
Když někdo používá dědičnost často, tak ji nejspíš používat neumí.

Ale pravdu bych se vyhnul ideologickým poučkám "dědičnost nepoužíváme, protože je to prasárna" - vždy je důležité hlavně vědět jaké konkrétní problémy vznikají.

S tymto uplne suhlasim.

(Kit zasa podsuva svoje predstavy o tom, co si myslim, aj ked som nic take nenapisal)
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 09:17:59
Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?
Já bych to řekl takhle: když někdo umí používat dědičnost, tak ji používá málo.
Když někdo používá dědičnost často, tak ji nejspíš používat neumí.

Ale pravdu bych se vyhnul ideologickým poučkám "dědičnost nepoužíváme, protože je to prasárna" - vždy je důležité hlavně vědět jaké konkrétní problémy vznikají.

S tymto uplne suhlasim.

(Kit zasa podsuva svoje predstavy o tom, co si myslim, aj ked som nic take nenapisal)

Pořád tady píšeš o redukci opakování kódu, která s dědičností nesouvisí, tak co si mám myslet?
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 09:20:32
Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?
Já bych to řekl takhle: když někdo umí používat dědičnost, tak ji používá málo.
Když někdo používá dědičnost často, tak ji nejspíš používat neumí.

Ale pravdu bych se vyhnul ideologickým poučkám "dědičnost nepoužíváme, protože je to prasárna" - vždy je důležité hlavně vědět jaké konkrétní problémy vznikají.

S tymto uplne suhlasim.

(Kit zasa podsuva svoje predstavy o tom, co si myslim, aj ked som nic take nenapisal)

Pořád tady píšeš o redukci opakování kódu, která s dědičností nesouvisí, tak co si mám myslet?

Dedicnost je dobra a nepouziva sa na redukciu opakovania kodu. (aj ked k redukcii opakovania kodu moze dojst, ak je to tak spravne)  Staci taketo vyjadrenie?
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 09:31:35
Dedicnost je dobra a nepouziva sa na redukciu opakovania kodu. (aj ked k redukcii opakovania kodu moze dojst, ak je to tak spravne)  Staci taketo vyjadrenie?

Ano, stačí.

Začátky chybného uvažování je již ve špatných učebnicích, ve kterých jsou nesmysly typu "B extends A" nebo "Bar extends Foo". Přitom ani v jednom případě to neplatí. Chudák čtenář si pak myslí, že se dědičnost používá na redukci opakování kódu a už se veze po špatné koleji.
Název: Re:Dědičnost dnes
Přispěvatel: n 16. 01. 2017, 09:55:31
Dedicnost je dobra a nepouziva sa na redukciu opakovania kodu. (aj ked k redukcii opakovania kodu moze dojst, ak je to tak spravne)  Staci taketo vyjadrenie?

Ano, stačí.

Začátky chybného uvažování je již ve špatných učebnicích, ve kterých jsou nesmysly typu "B extends A" nebo "Bar extends Foo". Přitom ani v jednom případě to neplatí. Chudák čtenář si pak myslí, že se dědičnost používá na redukci opakování kódu a už se veze po špatné koleji.

Tojo, vizualne uz na prvni pohled to je blbe, ale doufam, ze snad ve vsech ucebnicich nekolikrat zdurazni tu zakladni, nutnout podminku cos psal vyse.
Název: Re:Dědičnost dnes
Přispěvatel: jpu 16. 01. 2017, 10:04:54
dedicnost bezne pouzivam napr. (C#):

Kód: [Vybrat]
public class ViewModelBase : INotifyPropertyChanged
{
    public void NotifyPropertyChanged ....

}

public class CustomerViewModel : ViewModelBase
{
}

Citace
inheritance hierarchy represents an "is-a" relationship and not a "has-a" relationship
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 10:13:45
Začátky chybného uvažování je již ve špatných učebnicích, ve kterých jsou nesmysly typu "B extends A" nebo "Bar extends Foo". Přitom ani v jednom případě to neplatí. Chudák čtenář si pak myslí, že se dědičnost používá na redukci opakování kódu a už se veze po špatné koleji.

Tojo, vizualne uz na prvni pohled to je blbe, ale doufam, ze snad ve vsech ucebnicich nekolikrat zdurazni tu zakladni, nutnout podminku cos psal vyse.

Je také nutné si uvědomit, jak se takové učebnice čtou. Čtenář se začte do zdrojového kódu, protože je hezky vyznačen, ale tu důležitou "omáčku kolem" si buď nepřečte, anebo přečte a nepochopí. V hlavě mu pak zbude jen ten nepovedený příklad s tím, že to snad pochopí později.

Ukázkovým příkladem chybného pochopení dědičnosti je pak třeba známý "Cyklista extends Žába", který nepopisuje cyklistu, který umí skákat, ale žábu, která umí jezdit na kole. A takových "žab" bývají bohužel plné zdrojáky.
Název: Re:Dědičnost dnes
Přispěvatel: dustin 16. 01. 2017, 10:28:38
Jo, na příklady Foo a Bar jsem také alergický (nejen v ukázkách dědičnosti), daleko užitečnější by bylo používat reálné příklady. Ale nemyslím si, že by rozumný vývojář nepochopil, že jde o "is a" a ne o "has a".
Název: Re:Dědičnost dnes
Přispěvatel: karel 16. 01. 2017, 11:54:23
Většině diskutujících uniká je, že dědičnost v jazycích jako Java, C++ apod. representuje vlastně 3 koncepty. Je to dědění dat (většinou nechci, porušuje zapouzdření, lepší je použít skládání), dědění chování (většinou nechci, vede k fragile base class a porušuje zapouzdření), definice rozhraní(většinou chci, pomáhá k využití polymorfismu, pomáhá strukturovat kód - neprogramuju proti implementaci). Interface je dokonce často oddělen od dědičnosti - Java, C#.

Podle mě OOP jazyk vůbec nemusí umožňovat dědit data a chování a přesto se v tom bude dobře programovat bez duplikování kódu. Protože často ani "is a" neznamená, že je správné použít dědění ve smyslu dědění chování nebo dat a jde mi jen o interface. Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

IMHO podle mě pro objektové programování je nejdůležitější programovat proti rozhraní, dodržovat zapouzdření a každá třída musí mít jenom jednu roli (signle responsibility). Pokud tohle dodržuju, dědičnost (nepočítám implementaci interface) mi z programu z velké části zmizí a spíš slouží k modelování dat než k deduplikaci kódu.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 12:08:25
Používáte dnes v OOP často dědičnost? Není ta doba už pryč?

Dědičnost nemá co dělat s dobou či módou, je to technologická záležitost! Podle módy programují lempli.

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í.

Dědičnost vznikla jako prostředek k odstranění duplicity kódu, jinak byste musel všechny specializované třídy řešit téměř kompletním přepisem. Jde to, ale porušuje to DRY, přidělává práci a je náchylné k chybám. (Pro rýpaly: Delegování dědičnost nenahrazuje, protože funguje jinak.)
Později ji začaly některé jazyky (s typovým polymorfismem - Java, ...) používat pro dosažení polymorfismu.

Chápu ještě využití polymorfismu, ale to není až tak časté.

Polymorfismus je jen nástrojem, je logické, že když jej vývojáři nezvládají, tak se s ním nesetkáte.

Ale celkově to moc dnes nedává smysl...

Jak to myslíte? Ono se něco změnilo?
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 16. 01. 2017, 12:15:59
Používáte dnes v OOP často dědičnost? Není ta doba už pryč?

Dědičnost nemá co dělat s dobou či módou, je to technologická záležitost! Podle módy programují lempli.


To je moc hezka teorie. Ale i kdyz jsi byl machr pred dvaceti lety, tak jsi proste programoval jinak nez machr dneska. A neni to zdaleka jenom tim, ze machr dneska ma k ruce jine IDE a jine jazyky.

Pokud tomu nechces rikat "moda", tak zkus trebas neutralnejsi "kultura".
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 12:18:00
Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

Někdo ještě používá protected atributy? Měly by být všechny privátní.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 12:19:18
... Prostě třeba před 20 lety to bylo celkem cool a dost se to používalo. Dnes se ví, že dědičnost je spíše zlo, tak jsem chtěl vědět, jestli pro ní někdo nemá nějaké nové a dobré využítí.

Znovu: Dědičnost není věcí módy, použití dědičnosti je v OOP poměrně přesně určeno, podstata a využití je stále stejné.

Máme plno nových jazyků a přístupů, takže všechno se dost mění.

Buďte klidný, na podstatě a účelu OOP se nic nezměnilo.

Utility class je také zlo, ne?

To je taková ta funkční třída? To je pochopitelně koncepční chyba, protože její metody patří jinam, ale někdy se jí nedá vyhnout vzhedem k chybějící funkcionalitě existujících tříd.

Tak jasný, v patternech je jí plno, ale je otázkou, jestli jsou ty patterny dnes dobré.

Některé vzory jsou poplatné jazykům, pro které vznikly, ale obecně dokud se nemění principy, vzory zůstávají.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 12:22:27
Problém je používání pevných typů namísto rozhraní. K tomu dědičnost svádí.

Jak může dědičnost svádět k záměně za rozhraní???
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 12:25:26
Jestli používáš OOP a nepoužíváš dědičnost, tak tvoje znalost OOP busí být opravdu bídná.

Jsou objektové jazyky, ve kterých se bez dědičnosti obejdete, nebo které ji nemají.
Název: Re:Dědičnost dnes
Přispěvatel: Tomáš Roll 16. 01. 2017, 12:29:11
Jestli používáš OOP a nepoužíváš dědičnost, tak tvoje znalost OOP busí být opravdu bídná.

Jsou objektové jazyky, ve kterých se bez dědičnosti obejdete, nebo které ji nemají.

A taky existuje Brainfuck
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 12:32:26
V některých jazycích je dědičnost takové "nutné zlo", ale dá se jí vyhnout (a je to žádoucí), viz např. Go. Pokud někdo "miluje" dědičnost, není moc dobrý vývojář.
Např. v Javě jsou knihovny dost mizerně navržené, takže se všude dědí, naopak např. v ObjC (Cocoa) se používají převážně rozhraní a shluky tříd, což je mnohem lepší v mnoha ohledech (dědičnost je jen u tříd pro GUI a měnitelných kolekcích).

On obecně vývojář, který má citový vztah k technologiím, asi nebude v pořádku.
Jak nahrazuje rozhraní dědičnost?
Název: Re:Dědičnost dnes
Přispěvatel: karel 16. 01. 2017, 12:42:08
Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

Někdo ještě používá protected atributy? Měly by být všechny privátní.
Souhlas a tady se nabízí otázka, když je ta třída správně zapouzdřená opravdu z ní potom chci dědit? IMHO nechci a je lepší použít skládání.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 12:54:17
...Osobne riesim duplicitu kodu bud delegaciou, alebo worker objectom, teraz k tomu pribudli aj funkcie...

Jak se řeší vnitřní funkcionalita objektu delegací, workerem či funkcí?
Název: Re:Dědičnost dnes
Přispěvatel: n 16. 01. 2017, 12:56:27

Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je presny priklad toho, proc jsou s tim problemy. Lidi s nastrojema neumi pracovat a pak si stezuji, ze jsou ty nastroje nanic. Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public. Navzdy se zavazujete k tomu rozhrani a uz to nikdy nesmite menit. Lidi si to ale neuvedomuji a pak svaluji vinu napriklad na dedicnost, ale ten problem je uplne nekde jinde.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 13:00:58
...Použití dědičnosti zpravidla redukuje opakování kódu, i když to není primárním účelem.

A co je primárním účelem? Polymorfismus? Pouze u jazyků s  podtypovým polymorfismem je to nutností.
Název: Re:Dědičnost dnes
Přispěvatel: karel 16. 01. 2017, 13:02:15

Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je presny priklad toho, proc jsou s tim problemy. Lidi s nastrojema neumi pracovat a pak si stezuji, ze jsou ty nastroje nanic. Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public. Navzdy se zavazujete k tomu rozhrani a uz to nikdy nesmite menit. Lidi si to ale neuvedomuji a pak svaluji vinu napriklad na dedicnost, ale ten problem je uplne nekde jinde.
Já jsem spíš chtěl říct, že většinou pokud se zbavíš protected proměnných, zbavíš se i důvodu pro použití dědičnosti a vrátíš se zase zpět k "posílání zpráv" mezi objekty. Dědičnost není celá špatně, ale historicky je hodně nadužívaná a svádí k tomu právě i způsob výuky OOP.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 13:13:11
Podporuje to vznik roznych zkriplenych objektov, ktorych ucel nie je jasny, plus si tym programator zbytocne zahlcuje hierarchiu dedicnosti.

Ked sa pouzije casting potomka na rodica, mal by tento casting v ramci polymorfizmu fungovat. Pri DRY objektoch tomu tak nebyva.

Jak dědičnost kriplí instance podtříd? Jak dědičnost způsobuje bezúčelnost objektů? Jak specializace zahlcuje hierarchii? Co má společného přetypování s polymorfismem? Co je "DRY objekt"? O čem to vůbec mluvíte???
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 16. 01. 2017, 13:17:00

Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je presny priklad toho, proc jsou s tim problemy. Lidi s nastrojema neumi pracovat a pak si stezuji, ze jsou ty nastroje nanic. Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public. Navzdy se zavazujete k tomu rozhrani a uz to nikdy nesmite menit. Lidi si to ale neuvedomuji a pak svaluji vinu napriklad na dedicnost, ale ten problem je uplne nekde jinde.
Já jsem spíš chtěl říct, že většinou pokud se zbavíš protected proměnných, zbavíš se i důvodu pro použití dědičnosti a vrátíš se zase zpět k "posílání zpráv" mezi objekty. Dědičnost není celá špatně, ale historicky je hodně nadužívaná a svádí k tomu právě i způsob výuky OOP.

Moje podezreni je, ze primarni duvod je, ze dedicnost je tezka. Takze se ji venuje hodne prostoru pri vyuce. A proto skoro vsichni hned do zacatku dostanou klapky pred oci. (A nasekaji spoustu problemu, protoze dedicnost je tezka. A protoze nasekali problemy, tak stoji za to dedicnost ucit co nejdusledneji ;) )
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 13:37:31
Většině diskutujících uniká je, že dědičnost v jazycích jako Java, C++ apod. representuje vlastně 3 koncepty. Je to dědění dat (většinou nechci, porušuje zapouzdření, lepší je použít skládání), dědění chování (většinou nechci, vede k fragile base class a porušuje zapouzdření), definice rozhraní(většinou chci, pomáhá k využití polymorfismu, pomáhá strukturovat kód - neprogramuju proti implementaci). Interface je dokonce často oddělen od dědičnosti - Java, C#.

3x chyba:
Jak porušuje dědění zapouzdření?!
Dědění chování potřebuju, abych jej nemusel vytvářet znovu.
Na definici rozhraní je rozhraní, k tomu třída neslouží!

Protože často ani "is a" neznamená, že je správné použít dědění ve smyslu dědění chování nebo dat a jde mi jen o interface.

??? Uveďte příklad.
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 14:19:18
Podporuje to vznik roznych zkriplenych objektov, ktorych ucel nie je jasny, plus si tym programator zbytocne zahlcuje hierarchiu dedicnosti.

Ked sa pouzije casting potomka na rodica, mal by tento casting v ramci polymorfizmu fungovat. Pri DRY objektoch tomu tak nebyva.

Jak dědičnost kriplí instance podtříd? Jak dědičnost způsobuje bezúčelnost objektů? Jak specializace zahlcuje hierarchii? Co má společného přetypování s polymorfismem? Co je "DRY objekt"? O čem to vůbec mluvíte???

Vytrhavate veci z kontextu a reagujete mimo misu. Najprv si precitajte, o com som pisal a potom reagujte. Zda sa ze si musite doplnit znalosti.

"DRY objekt", som pouzil ako pejorativum. Take neexistuje, ale z kontextu je jasne hadam na co myslim.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 14:21:21
Někdo ještě používá protected atributy? Měly by být všechny privátní.

V okamžiku, kdy použijete vlastnosti a metody private, oddělíte od sebe prostory jednotlivých tříd v daném řetězu dědičnosti, protože se k těmto prvkům již nedostanete. To je zcela odlišný koncept od použití protected, kdy každá třída je souhrnem svých nadtříd. Jestliže dědím proto, abych mohl využívat již hotové a specializovat, je pro mě skytí vlastností v nadtřídách kontraproduktivní. Neboli všechny private určitě ne.
Název: Re:Dědičnost dnes
Přispěvatel: Kit 16. 01. 2017, 14:33:57
Někdo ještě používá protected atributy? Měly by být všechny privátní.

V okamžiku, kdy použijete vlastnosti a metody private, oddělíte od sebe prostory jednotlivých tříd v daném řetězu dědičnosti, protože se k těmto prvkům již nedostanete. To je zcela odlišný koncept od použití protected, kdy každá třída je souhrnem svých nadtříd. Jestliže dědím proto, abych mohl využívat již hotové a specializovat, je pro mě skytí vlastností v nadtřídách kontraproduktivní. Neboli všechny private určitě ne.

Pokud mám ve třídě privátní atributy a veřejné metody, tak pro potomky budou přístupné pouze metody. Víc nepotřebuji. Potomek nemá důvod na atributy sahat, o to se starají metody nadtřídy.
Název: Re:Dědičnost dnes
Přispěvatel: spasitel 16. 01. 2017, 14:37:35
ajajaaaj, dalsi diskuze jde do kytek. kazdej si tady honi svy ego, ma svuj nazor a ten je proste neprustrelnej. panove, jdete na leceni, protoze uroven vasich prispevku ma hodnotu kecu v hospode.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 14:38:04
Souhlas a tady se nabízí otázka, když je ta třída správně zapouzdřená opravdu z ní potom chci dědit? IMHO nechci a je lepší použít skládání.

Specializace nemá se zapouzdřením co dělat, zapouzdření můžete porušit zpřístupněním metody či vlastnosti na public nebo metodou public, ne vytvořením podtřídy, která nadtřídu nijak neovlivňuje.
Skládáním nemůžete změnit vnitřní chování objektu, tím můžete pouze využít vnější funkcionalitu skládaného objektu, a to je dost podstatný rozdíl. Takže univerzální použití skládání padá.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 14:45:28
Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je běžným důsledkem nejen chybného použití dědění a skládání, ale taky chybným rozdělením funkcionalit mezi třídy a v důsledku chybným zapouzdřením a polymorfismem. Na to přesný návod neexistuje, to se prostě musí umět. Každopádně OOP za to nemůže.

...Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public...

To je samozřejmě nesmysl, právě protected dovoluje díky dědičnosti znovuvyužití hotové funkcionality v rámci zřetězení tříd bez nutnosti složitého delegování či opakování, na zapouzdření instance to pochopitelně vliv nemá.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 14:55:36
Moje podezreni je, ze primarni duvod je, ze dedicnost je tezka...

Dědičnost vůbec není těžká, je jen složitě vysvětlovaná, a to ještě na jazycích, co ji potřebují k polymorfismu, takže se tak mísí 2 koncepty a posluchač v tom má bordel.
Dědičnost si stačí představit jako tu původní, smalltalkovou (vše protected), kdy každá podtřída je to samé, jako bych opsal celou nadtřídu a nahradil/doplnil jen to, co je jiné. Neboli dědičnost lze nahradit právě takovýmto přepisováním celých tříd (s následným porušením DRY). Teprve potom lze přidat vysvětlení doprasených implementací z jiných jazyků.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 15:00:04
Vytrhavate veci z kontextu a reagujete mimo misu. Najprv si precitajte, o com som pisal a potom reagujte. Zda sa ze si musite doplnit znalosti.

"DRY objekt", som pouzil ako pejorativum. Take neexistuje, ale z kontextu je jasne hadam na co myslim.

Četl jsem vše od začátku. Asi mluvíme každý o něčem jiném. Odkazy k doplnění znalostí by mohly nedorozumění vyjasnit.
Název: Re:Dědičnost dnes
Přispěvatel: SB 16. 01. 2017, 15:12:43
Pokud mám ve třídě privátní atributy a veřejné metody, tak pro potomky budou přístupné pouze metody. Víc nepotřebuji. Potomek nemá důvod na atributy sahat, o to se starají metody nadtřídy.

Veřejné metody neslouží k přístupu uvnitř třídy (i když můžou), ale k přístupu z vně instance. V případě, že budou všechny public, tak jste nemusel používat dědění, ale skládání, protože část nadtřídy se v instanci chová jako složený, zapouzdřený, samostatný objekt. Otázkou je, zda je takový model v pořádku.

Opět: Vaše pojetí nadtřídy je pojetím izolované entity vložené do podtřídy. Přitom podstatou specializace je pravidlo "is-a", takže není důvod, aby podtřída nepracovala s entitami z nadtřídy, dokonce je to záhodno. Máte-li potřebu oddělovat mezi sebou části z řetězce hierarchie (přičemž pořád platí, že nadtřída je podtřídami nedotčena), snažíte se vyrábět něco jako skládání.
Název: Re:Dědičnost dnes
Přispěvatel: karel 16. 01. 2017, 15:20:54
Většině diskutujících uniká je, že dědičnost v jazycích jako Java, C++ apod. representuje vlastně 3 koncepty. Je to dědění dat (většinou nechci, porušuje zapouzdření, lepší je použít skládání), dědění chování (většinou nechci, vede k fragile base class a porušuje zapouzdření), definice rozhraní(většinou chci, pomáhá k využití polymorfismu, pomáhá strukturovat kód - neprogramuju proti implementaci). Interface je dokonce často oddělen od dědičnosti - Java, C#.

3x chyba:
Jak porušuje dědění zapouzdření?!
Dědění chování potřebuju, abych jej nemusel vytvářet znovu.
Na definici rozhraní je rozhraní, k tomu třída neslouží!

No právě, pokud neslouží na definici rozhraní a nemá protected metody nebo proměnné, nemá cenu z ní dědit, můžu k ní přistupovat z venku. Pokud má protected metody nebo proměnné, můžu z potomka ovlivnit její chování, takže jsem rozbil zapouzdření předka.


Protože často ani "is a" neznamená, že je správné použít dědění ve smyslu dědění chování nebo dat a jde mi jen o interface.

??? Uveďte příklad.
Např. návrhový vzor Role https://en.wikipedia.org/wiki/Role_Class_Model Můžeš třeba definovat školní systém tak, že Je třída Osoba, z ní dědí Učitel a Student. Ze Studenta dědí BakalářskýStudent a MagisterskýStudent. Celý systém je podle pravidla "is a" správně. Jenom neumožňuje přechod z bakaláře na magistra nebo ze studenta na učitele. "is a" je podmínka nutná, ale ne dostačující.
Název: Re:Dědičnost dnes
Přispěvatel: n 16. 01. 2017, 15:21:45
Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je běžným důsledkem nejen chybného použití dědění a skládání, ale taky chybným rozdělením funkcionalit mezi třídy a v důsledku chybným zapouzdřením a polymorfismem. Na to přesný návod neexistuje, to se prostě musí umět. Každopádně OOP za to nemůže.

...Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public...

To je samozřejmě nesmysl, právě protected dovoluje díky dědičnosti znovuvyužití hotové funkcionality v rámci zřetězení tříd bez nutnosti složitého delegování či opakování, na zapouzdření instance to pochopitelně vliv nemá.
Trochu jsem to prehnal se silou vyjadreni, ale: tim ze date neco protected, se zavazujete k udrzovani rozhrani stejne jako kdyby to byla public, pokud je dana trida deditelna. Pouze k temto metodam nema pristup primy klient tridy, ale ten ktery ji dedi. Nemuzete odstranovat protected metody ani menit jejich funkci(respektive muzete, ale rovna se to zmene rozhrani, pokud neni zabraneni dedeni.)
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 16:02:31
Vytrhavate veci z kontextu a reagujete mimo misu. Najprv si precitajte, o com som pisal a potom reagujte. Zda sa ze si musite doplnit znalosti.

"DRY objekt", som pouzil ako pejorativum. Take neexistuje, ale z kontextu je jasne hadam na co myslim.

Četl jsem vše od začátku. Asi mluvíme každý o něčem jiném. Odkazy k doplnění znalostí by mohly nedorozumění vyjasnit.

Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting
Název: Re:Dědičnost dnes
Přispěvatel: Karel (jiný) 16. 01. 2017, 16:07:50
Dědičnost používám tam, kde se potřeba. Je nutné, aby byl splněn výrok "potomek" _je_ "rodič". Například Automobil je Vozidlo, Faktura je Doklad, Kvádr je Těleso apod. Zároveň musí být v programu možná zaměnitelnost potomka a rodiče. Pokud tato pravidla nejsou splněna, dědičnost nelze použít.

Tohle je v zásadě pravda, bohužel řada lidí nedočte k tomu "zároveň". Vidí "Faktura je Doklad" a jedou. Jenže ona i když faktura je doklad, tak spolu ve skutečnosti nemají nic společného. Příjemka je taky doklad. Stejně tak výdej materiálu do spotřeby nebo zálohová faktura. Ale nejsou zaměnitelné. Mají různé atributy, jiné metody a vlastně i jiné návaznosti (něco hýbá skladem, něco jen účetnictvím etc.) Program je pak beztak prolezlý "instanceof". Společný mají jen order type a order number. A to ještě ne konzistentně, takže pro některé typy dokladů je primárním klíčem tahle dvojice, ale pro jiné je primárním klíčem jen order number a pak pár, kde je součástí klíče i order suffix nebo order revision. Hlavně ale že je to OOP a že to v UML vypadá cool.

Prostě souhlasím s vámi, jen bych rád "možná zaměnitelnost potomka a rodiče" viděl v každé učebnici na prvním místě.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 16. 01. 2017, 17:03:11
Jste nejlepší! Je to dobré téma a plno zajímavých pohledů.

Dědičnost používám tam, kde se potřeba. Je nutné, aby byl splněn výrok "potomek" _je_ "rodič". Například Automobil je Vozidlo, Faktura je Doklad, Kvádr je Těleso apod. Zároveň musí být v programu možná zaměnitelnost potomka a rodiče. Pokud tato pravidla nejsou splněna, dědičnost nelze použít.

Tohle je v zásadě pravda, bohužel řada lidí nedočte k tomu "zároveň". Vidí "Faktura je Doklad" a jedou. Jenže ona i když faktura je doklad, tak spolu ve skutečnosti nemají nic společného. Příjemka je taky doklad. Stejně tak výdej materiálu do spotřeby nebo zálohová faktura. Ale nejsou zaměnitelné. Mají různé atributy, jiné metody a vlastně i jiné návaznosti (něco hýbá skladem, něco jen účetnictvím etc.) Program je pak beztak prolezlý "instanceof". Společný mají jen order type a order number. A to ještě ne konzistentně, takže pro některé typy dokladů je primárním klíčem tahle dvojice, ale pro jiné je primárním klíčem jen order number a pak pár, kde je součástí klíče i order suffix nebo order revision. Hlavně ale že je to OOP a že to v UML vypadá cool.

Prostě souhlasím s vámi, jen bych rád "možná zaměnitelnost potomka a rodiče" viděl v každé učebnici na prvním místě.

A jak teda obecně řešit problém, kdy mám třeba 5 různých typů dat, které trochu spolu souvisí, ale dědičnost tam nejde použít přesně proto, co jsi napsal. 5 různých tříd nesdílejích nic? 5 různých služeb pracující s nimi? Nebo použít pro služby generickou službu? A co ukládání? Je to obecně složité téma, ale jen tak jestli máš nějaké tipy k tomu. Málo dat a hodně logiky je jednodušší, ale když jsou data, která je potřeba mít, tak se to komplikuje.
Název: Re:Dědičnost dnes
Přispěvatel: Kamil Podlešák 16. 01. 2017, 18:03:59
Jeden ze základních problémů používání OOP je snaha pomocí dědičnosti (class hierarchy) modelovat realitu (nebo obecně doménu).

Ano, byla to jedna ze základních tezí vedoucí k propagaci a rozšíření OOP. Ale po třiceti (čtyřiceti?) letech si můžeme přiznat, že tohle naprosto selhalo.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 16. 01. 2017, 18:11:58
Jeden ze základních problémů používání OOP je snaha pomocí dědičnosti (class hierarchy) modelovat realitu (nebo obecně doménu).

Ano, byla to jedna ze základních tezí vedoucí k propagaci a rozšíření OOP. Ale po třiceti (čtyřiceti?) letech si můžeme přiznat, že tohle naprosto selhalo.
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í.
Název: Re:Dědičnost dnes
Přispěvatel: bob 16. 01. 2017, 19:26:11
Např. návrhový vzor Role https://en.wikipedia.org/wiki/Role_Class_Model Můžeš třeba definovat školní systém tak, že Je třída Osoba, z ní dědí Učitel a Student. Ze Studenta dědí BakalářskýStudent a MagisterskýStudent. Celý systém je podle pravidla "is a" správně. Jenom neumožňuje přechod z bakaláře na magistra nebo ze studenta na učitele. "is a" je podmínka nutná, ale ne dostačující.

Jsi to spatne pochopil, na tom obrazku dole na te vazbe, je napsano "is a", ale neznamena to dedicnost, protoze ta se znaci v tom diagramu prazdnym trojuhelnickem. Praveze ta skola je modelovy priklad toho, ze se ma pouzit vazba "has a" a ne dedicnost.

Student nededi od cloveka. Cozpak je student vic clovekem nez delnik? Student ma smysl jen ve vztahu ke skole a ten vztah si nekdo vymyslel, je to pravni termin. Ty MAS VZTAH ("has a") vuci skole a tim je "student", "ucitel" atd... A muzes mit vic roli. Prave znamnka toho, ze by jsi potreboval roli zmenit nebo muzes mit vic roli (muzes byt ucitel i student i skolink zarovne? Muzes proc by ne.) je dalsi dobre voditko, proc to neni dedicnost.

Obecne plati, ze by jsi mel vzdycky delat co nejmene zavislosti. Literatura tomu rika loosely coupling, nicmene malokdo chape co tenhle buzz word znamena. Vazba "is a" je to nejsilnejsi co muze byt, kdyz  necim jsi, tak uz nemuzes byt  nicim jinym (ve svete trid). "has a",  casto implementovana jako promenna ve tride je mnohem volnejsi a kdekoliv si tak muzes rict, ze trida neco vlastni, tak je vzdy lepsi ji pouzit a kdyz si nejsem jistej, tak davam "has a".
Název: Re:Dědičnost dnes
Přispěvatel: MartinBeran 16. 01. 2017, 20:55:39
Připadá mi, že v této diskusi se míchá dědičnost jako koncept používaný při modelování reality v softwaru a dědičnost jako nástroj programovacího jazyka. A většina argumentace se implicitně točí kolem informačních systémů. Jenže OOP se používá i jinde. Např. GUI toolkity používají OOP již desítky let - namátkou Turbo Vision, Object Windows, GTK+, Qt. Dokonce k tomu nepotřebují ani OO jazyk (GTK+). V těchto aplikacích má použití dědičnosti s hlubokou polymorfní hierarchií hodně dobrý smysl. Naopak mi není moc jasné, proč se data v informačním systému snažit modelovat pomocí objektů a následně se hádat o různé aspekty OOP, když by lépe posloužil relační databázový model. Zvlášť, když data jsou už často v relační databázi uložena.
Název: Re:Dědičnost dnes
Přispěvatel: BoneFlute 16. 01. 2017, 21:22:17
...Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public...

To je samozřejmě nesmysl, právě protected dovoluje díky dědičnosti znovuvyužití hotové funkcionality v rámci zřetězení tříd bez nutnosti složitého delegování či opakování, na zapouzdření instance to pochopitelně vliv nemá.
A není to spíše naopak? Že protected umožňuje horkotěžko vyladěné chování rodičovské třídy nabourat a znepřehlední flow života instance, namísto jednoduchého, přímočarého a hlavně dobře otestovatelného delegování?

Protected je ekvivalent public. A jak tu bylo řečeno, nese si problém s tím, že se jedná o veřejné api, které je nutné dodržet. Což zvyšuje komplexitu.
Název: Re:Dědičnost dnes
Přispěvatel: BoneFlute 16. 01. 2017, 21:39:07
Za mě se domnívám, že dědičnost tak jak je implementována ve většině jazycích je na pytel.

Jako problém vidím hlavně to, že někteří tvrdí, že dědičnost slouží k tomu, abych znovupoužil existující funkcionalitu. I kdyby to byla pravda, tak je problém, že většina jazyků nedokáže oddělit znovupoužití chování, od definice vztahu mezi třídami. Jak tu SB popisoval, že Smaltalk má objekt, a ty ho vždycky přetěžuješ - to je sice hezký, ale s tím poděděným chováním si zároveň podědil i všechny ty vztahy. Což u typovaného jazyka může bejt dost problém. Další problém je v tom, že čím delší linie, tím méně se člověku chce opravovat chybné chování předka. Což je trapné.

Přijde mi mnohem šikovnější a čistější rozdělení v některých moderních jazycích. Jednak máš rozhraní/interface/class, a druhak máš trait/mixin. První slouží k určení vztahů, k vynucování požadavků na signaturu, etc. A to druhé slouží k reusable kódu. Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 16. 01. 2017, 21:47:25
Jste nejlepší! Je to dobré téma a plno zajímavých pohledů.

Dědičnost používám tam, kde se potřeba. Je nutné, aby byl splněn výrok "potomek" _je_ "rodič". Například Automobil je Vozidlo, Faktura je Doklad, Kvádr je Těleso apod. Zároveň musí být v programu možná zaměnitelnost potomka a rodiče. Pokud tato pravidla nejsou splněna, dědičnost nelze použít.

Tohle je v zásadě pravda, bohužel řada lidí nedočte k tomu "zároveň". Vidí "Faktura je Doklad" a jedou. Jenže ona i když faktura je doklad, tak spolu ve skutečnosti nemají nic společného. Příjemka je taky doklad. Stejně tak výdej materiálu do spotřeby nebo zálohová faktura. Ale nejsou zaměnitelné. Mají různé atributy, jiné metody a vlastně i jiné návaznosti (něco hýbá skladem, něco jen účetnictvím etc.) Program je pak beztak prolezlý "instanceof". Společný mají jen order type a order number. A to ještě ne konzistentně, takže pro některé typy dokladů je primárním klíčem tahle dvojice, ale pro jiné je primárním klíčem jen order number a pak pár, kde je součástí klíče i order suffix nebo order revision. Hlavně ale že je to OOP a že to v UML vypadá cool.

Prostě souhlasím s vámi, jen bych rád "možná zaměnitelnost potomka a rodiče" viděl v každé učebnici na prvním místě.

A jak teda obecně řešit problém, kdy mám třeba 5 různých typů dat, které trochu spolu souvisí, ale dědičnost tam nejde použít přesně proto, co jsi napsal. 5 různých tříd nesdílejích nic? 5 různých služeb pracující s nimi? Nebo použít pro služby generickou službu? A co ukládání? Je to obecně složité téma, ale jen tak jestli máš nějaké tipy k tomu. Málo dat a hodně logiky je jednodušší, ale když jsou data, která je potřeba mít, tak se to komplikuje.
Takové třídy můžou sdílet rozhraní. Nebo se dá udělat cluster tříd. Nakonec vždy záleží na jazyce, co dovolí použít. Např. v Go můžu udělat typový alias a přidat k němu metody. V některých jazycích to jde i bez aliasu. Ono těch možností je více a v každém jazyce je idiomatické něco jiného.
Název: Re:Dědičnost dnes
Přispěvatel: balki 16. 01. 2017, 22:41:20
Přijde mi mnohem šikovnější a čistější rozdělení v některých moderních jazycích. Jednak máš rozhraní/interface/class, a druhak máš trait/mixin. První slouží k určení vztahů, k vynucování požadavků na signaturu, etc. A to druhé slouží k reusable kódu. Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

Traity su velmi sikovny koncept. Daju sa pomocou nich  "lepit objekty", podobne ako v subjektovo-orientovanom programovani. (Samozrejme, co do moznosti su slabsie ako SOP, ale aspon cast pokryvaju)  Javove som este neskusal, ale tie v scale boli velmi fajn.
Název: Re:Dědičnost dnes
Přispěvatel: anonym 16. 01. 2017, 23:21:57
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.

Možná se tím neřídí proto, že se tím řídit nedá, protože to samotné pravidlo je blbost.

Příklad, kde tvou zmíněné pravidlo platí: je potřeba načítat data ze souboru, jeden řádek představuje vektor dat, ty se mají vložit do databáze. Musíš zpracovávat po dávkách, protože soubor může mít i několik gigabajtů. Každý soubor představuje jakoby jednu tabulku a tabulek existuje více, než jedna.

Budeš tedy 100% v kódu mít tuhle závislost:

Kód: [Vybrat]
TransactionRow dědí Row
AccountRow dědí Row

TransactionTable dědí Table
AccountTable dědí Table

Table agreguje Row

Platí zde pravidlo, že potomek musí být speciální verzí předka? Ano, platí. A je tenhle model správný? Jo, je.
(mimochodem tohle má na webu i Martin Fowler jako alternativu k ORM)


Pak budeš mít jinačí situaci. Chceš namodelovat situaci objektů kolem nás, třeba proto, že je v palikaci budeš chtít vykreslovat v nějaké interaktivní hře. Takže řekněme, že zrovna děláš nádoby.

Kód: [Vybrat]
Hrnek dědí Nádoba
Sklenice dědí Nádoba

Voda dědí Náplň
Hrách dědí Náplň

Nádoba agreguje Náplň

Platí zde pravidlo, že potomek musí být speciální verzí předka? Ano, platí. A je tenhle návrh ok? Ne, je úplně na piču. A přitom kde je problém? Vždyť je to v podstatě úplně to samé, jako příklad Table - Row.

Rozdíl je akorát v tom, že když se snažíme svět kolem nás napasovat do OOP, tak to vždycky dopadne špatně. Přitom zrovna na reálném světě se OOP vysvětluje na těchto hloupých případech. Třeba že Auto má Kola a Dveře. Kdybychom to chtěli potom i takhle implementovat, protože děláme třeba hru, tak je to snad ten největší antipatern.

Tak jak je možné, že v jedné situaci je jedna a ta samá věc ok a v jinačí je úplně špatně, a jakto že to jde tak dobře poznat zrovna na příkladě, modelujeme-li relativně jasně zadaný úkon v rámci PC světa a dáme úplně v principu to samé do kontrastu s reálným světem?

Je to proto, protože reálný svět je velice složitý a kdyby se chtěl namodelovat, tak by vyšlo, že všechno dědí všechno, všechno agreguje všechno a závislosti v něm jdou těžko postihnout a ikdyby šly, vychází vícejaké možnosti jak něco namodelovat, a proč? Protože OOP je úplně napiču pokud jde o modelování reálného světa, je to jen paradigma v rámci malého světa počítačů.

Přitom, soubor na disku je rovněž reálná věc.

Z toho plyne malá úprava: OOP se má používat zcela účelově a má sloužit při zpřehlednění aplikace. Neplatí žádné pravidla typu "potomek musí být speciální verzí předka", platí jenom jedno pravidlo, "musí to být účelné a dávat to to smysl v závislosti na tom, co budeme dělat" a to i v případě, kdy se chce někdo vyhnout duplicitě v kódu.

Můj názor.





Název: Re:Dědičnost dnes
Přispěvatel: anonym 16. 01. 2017, 23:24:29
Zelenáč, prorok a junior Java programátor, léta páně 2017
Název: Re:Dědičnost dnes
Přispěvatel: anonym 16. 01. 2017, 23:36:04
A proto: neplatí žádný vztah, že Syn dědí Fotra, ani že Kolo dědí Auto, ani že Škodovka dědí Auto, ani že Škodovka dědí ČeskouPostkomunistickouIndustrializaci, ani další kraviny. Jsou prostě jen objekty, Syn, Fotr, Kolo, Auto. Jaká je mezi nima skutečna dědičnost nebo agregace není nikomu známo. Existuje jen ta, kterou budeme používat, jen účel. Podstatou dědičnosti není nějaký reálný stav, podstatou dědičnosti je ÚČEL.

Např. ve Spring frameworku se reálně žádná dědičnost nepoužívá, všechno je tam "flat". A není vůbec od věci, použít dědičnost rovněž pro vynutí se duplicitnímu kódu v aplikaci, kterou prasilo několik týmů a jsou tam jistá její specifika.
Název: Re:Dědičnost dnes
Přispěvatel: BoneFlute 17. 01. 2017, 00:19:16
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.

Možná se tím neřídí proto, že se tím řídit nedá, protože to samotné pravidlo je blbost.

Příklad, ...

Můj názor.

OK. Ale obávám se, že jsem tvou argumentaci nepochopil.

AccountRow dědí Row - je ok
Voda dědí Náplň - je také ok.

Zda to má nějaké rozumné použití je věc jiná.
Row i Náplň je interface, protože Voda i Hrách mají specifické chování a společné pro ně je jen to, že jej lze někam naplnit.

Nevidím problém.
Název: Re:Dědičnost dnes
Přispěvatel: n 17. 01. 2017, 07:39:54
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.)

Ve spouste veci souhlasim, ci mam ze mam jiny nazor je nepodstatne, ale k vyse citovane vete:
S timhle je problem, napriklad znamy problem: ctverec vs obdelnik
Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.
Název: Re:Dědičnost dnes
Přispěvatel: n 17. 01. 2017, 07:49:17
A proto: neplatí žádný vztah, že Syn dědí Fotra, ani že Kolo dědí Auto, ani že Škodovka dědí Auto, ani že Škodovka dědí ČeskouPostkomunistickouIndustrializaci, ani další kraviny. Jsou prostě jen objekty, Syn, Fotr, Kolo, Auto. Jaká je mezi nima skutečna dědičnost nebo agregace není nikomu známo. Existuje jen ta, kterou budeme používat, jen účel. Podstatou dědičnosti není nějaký reálný stav, podstatou dědičnosti je ÚČEL.

Tak trochu, obecne mate samozrejme pravdu, ale: Kdyz se budete divat jen na aktualni UCEL, tak to dopadne spatne, protoze prijde zakaznik a bude po vas chtit pridat funkcionalitu, a pokud budete hledet pri modelovani jen na aktualni UCEL, tak to nejspis budete cele prepisovat. Oplati se zamyslet uz pri navrhu nad tim, co ten objekt predstavuje a jake jsou jeho vazby na okoli.
Jinak OOP pouzivam casto, ale vsespasne neni. Bohuzel nektere jazyky (jako napr Java) vas nuti to pouzivat ke vsemu, i kdyz jsou veci, ke kterym se opravdu nehodi, protoze spoustu casu travite usilim navrhnout smysluplnou hierarchii, i kdyz to nema smysl.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 17. 01. 2017, 09:24:43
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.)

Ve spouste veci souhlasim, ci mam ze mam jiny nazor je nepodstatne, ale k vyse citovane vete:
S timhle je problem, napriklad znamy problem: ctverec vs obdelnik
Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.
Tohle se (nejen) tady řešilo už milionkrát a závěr vždy je, že mezi nimi dědičnost je. Jen na rootu se vždy najdou lidi, co o tom zas budou psát kraviny...  >:(
Název: Re:Dědičnost dnes
Přispěvatel: karel 17. 01. 2017, 09:30:41
Např. návrhový vzor Role https://en.wikipedia.org/wiki/Role_Class_Model Můžeš třeba definovat školní systém tak, že Je třída Osoba, z ní dědí Učitel a Student. Ze Studenta dědí BakalářskýStudent a MagisterskýStudent. Celý systém je podle pravidla "is a" správně. Jenom neumožňuje přechod z bakaláře na magistra nebo ze studenta na učitele. "is a" je podmínka nutná, ale ne dostačující.

Jsi to spatne pochopil, na tom obrazku dole na te vazbe, je napsano "is a", ale neznamena to dedicnost, protoze ta se znaci v tom diagramu prazdnym trojuhelnickem. Praveze ta skola je modelovy priklad toho, ze se ma pouzit vazba "has a" a ne dedicnost.

Student nededi od cloveka. Cozpak je student vic clovekem nez delnik? Student ma smysl jen ve vztahu ke skole a ten vztah si nekdo vymyslel, je to pravni termin. Ty MAS VZTAH ("has a") vuci skole a tim je "student", "ucitel" atd... A muzes mit vic roli. Prave znamnka toho, ze by jsi potreboval roli zmenit nebo muzes mit vic roli (muzes byt ucitel i student i skolink zarovne? Muzes proc by ne.) je dalsi dobre voditko, proc to neni dedicnost.

Obecne plati, ze by jsi mel vzdycky delat co nejmene zavislosti. Literatura tomu rika loosely coupling, nicmene malokdo chape co tenhle buzz word znamena. Vazba "is a" je to nejsilnejsi co muze byt, kdyz  necim jsi, tak uz nemuzes byt  nicim jinym (ve svete trid). "has a",  casto implementovana jako promenna ve tride je mnohem volnejsi a kdekoliv si tak muzes rict, ze trida neco vlastni, tak je vzdy lepsi ji pouzit a kdyz si nejsem jistej, tak davam "has a".
Mě přijde že spíš je chyba na tvém přijímači. Student je člověk a ne že student má člověka (a druhý model by byl člověk má roli student). A ten vzor je o tom, že můžeš vytvořit 2 modely bezchybné podle pravidel dědičnosti, ale to co je podstatné, že si musíš vybrat ten, který dává smysl pro tvůj problém.
Název: Re:Dědičnost dnes
Přispěvatel: bob 17. 01. 2017, 09:50:08
Mě přijde že spíš je chyba na tvém přijímači. Student je člověk a ne že student má člověka (a druhý model by byl člověk má roli student). A ten vzor je o tom, že můžeš vytvořit 2 modely bezchybné podle pravidel dědičnosti, ale to co je podstatné, že si musíš vybrat ten, který dává smysl pro tvůj problém.

Student neni clovek, student je role.
Druhy model, clovek ma roli studenta je spravne. A je to jidiny spravny model.

Nemuzes to dedit, protoze tam zadna dedicnost neni. Vybrat si muzes vzdycky, nekdy ale spatne.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 17. 01. 2017, 09:56:04
Mě přijde že spíš je chyba na tvém přijímači. Student je člověk a ne že student má člověka (a druhý model by byl člověk má roli student). A ten vzor je o tom, že můžeš vytvořit 2 modely bezchybné podle pravidel dědičnosti, ale to co je podstatné, že si musíš vybrat ten, který dává smysl pro tvůj problém.

Student neni clovek, student je role.
Druhy model, clovek ma roli studenta je spravne. A je to jidiny spravny model.

Nemuzes to dedit, protoze tam zadna dedicnost neni. Vybrat si muzes vzdycky, nekdy ale spatne.

Koukam, ze OOP sice deformuje mysleni, ale relacni pohled na vec ho dava do mixeru.
Název: Re:Dědičnost dnes
Přispěvatel: perceptron 17. 01. 2017, 10:29:48
Citace
Tohle se (nejen) tady řešilo už milionkrát a závěr vždy je, že mezi nimi dědičnost je. Jen na rootu se vždy najdou lidi, co o tom zas budou psát kraviny.
zaver je ten ze vy si myslite ze dedicnost je a ostatni su blazni (milionkrat)

Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 12:37:33
No právě, pokud neslouží na definici rozhraní a nemá protected metody nebo proměnné, nemá cenu z ní dědit, můžu k ní přistupovat z venku. Pokud má protected metody nebo proměnné, můžu z potomka ovlivnit její chování, takže jsem rozbil zapouzdření předka.

Tu první větu nechápu - dědění slouží k odvozování tříd.
Jestli vytvoříte novou podtřídu doplněnou o metody zpřístupňující některé vlastnosti, nadtřídy se to netýká a na zapouzdření jejích instancí to nemá (pochopitelně) vliv. S instancemi podtřídy si dělejte co chcete, jestli vytvoříte novou třídu děděním, nebo jejím celkovým přepisem (kde není žádný vztah k původní třídě), je buřt.

Např. návrhový vzor Role https://en.wikipedia.org/wiki/Role_Class_Model Můžeš třeba definovat školní systém tak, že Je třída Osoba, z ní dědí Učitel a Student. Ze Studenta dědí BakalářskýStudent a MagisterskýStudent. Celý systém je podle pravidla "is a" správně. Jenom neumožňuje přechod z bakaláře na magistra nebo ze studenta na učitele. "is a" je podmínka nutná, ale ne dostačující.

To je chybně namodelovaná situace. Učitel není Osobou, is-a neplatí. Použijte vzor Stav, Strategie, Role nebo něco podobného.
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 12:53:46
Trochu jsem to prehnal se silou vyjadreni, ale: tim ze date neco protected, se zavazujete k udrzovani rozhrani stejne jako kdyby to byla public, pokud je dana trida deditelna. Pouze k temto metodam nema pristup primy klient tridy, ale ten ktery ji dedi. Nemuzete odstranovat protected metody ani menit jejich funkci(respektive muzete, ale rovna se to zmene rozhrani, pokud neni zabraneni dedeni.)

Prosímvás, public sem teď nemíchejte, public určuje práci s instancí, ne uvnitř instance. Bavíme se o protected x private.
Samozřejmě, že protected znamená vazbu mezi třídou a podtřídou, ale to je přece podstata dědění. Když uděláte všechno private, jak bude podtřída využívat nadtřídu??? Chcete-li se vyhnout riziku změny v (třeba cizí) nadtřídě, udělejte si svoji samostatnou třídu. Tím ale přicházíte o výhodu dědění znovupoužitelnosti kódu, takže nejenže vám podtřídu nikdo nezkurví, ale ani se do ní nedostane požadovaná změna chování, opravy či rozšíření funkcionality. Prostě nedědíte. Jednoduché.
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 13:10:28
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 13:16:04
A jak teda obecně řešit problém, kdy mám třeba 5 různých typů dat, které trochu spolu souvisí, ale dědičnost tam nejde použít přesně proto, co jsi napsal. 5 různých tříd nesdílejích nic? 5 různých služeb pracující s nimi? Nebo použít pro služby generickou službu? A co ukládání? Je to obecně složité téma, ale jen tak jestli máš nějaké tipy k tomu. Málo dat a hodně logiky je jednodušší, ale když jsou data, která je potřeba mít, tak se to komplikuje.

Co je to "trochu souvisejí"?
Jestli ty entity nemají spolu (skoro) nic společného, tak je přece nebudu modelovat dohromady, protože nemají co sdílet, pak budou extra, jejich zpracování jinde bude extra a i způsob ukládání bude extra. I entity, které mají hodně společného, je možno klidně modelovat extra, ale přiděláte si tím práci.
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 13:19:25
Jeden ze základních problémů používání OOP je snaha pomocí dědičnosti (class hierarchy) modelovat realitu (nebo obecně doménu).

Ano, byla to jedna ze základních tezí vedoucí k propagaci a rozšíření OOP. Ale po třiceti (čtyřiceti?) letech si můžeme přiznat, že tohle naprosto selhalo.

Nebo někteří selhali? Vždyť i zde v diskusi někteří nedovedou rozpoznat generalizaci a specializaci.
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 13:23:57
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.
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 13:44:27
...Např. GUI toolkity používají OOP již desítky let...Dokonce k tomu nepotřebují ani OO jazyk (GTK+)...

Buďto jazyk konstrukce OOP umí, pak umí vytvářet objekty a je objektový, nebo je neumí, pak to nejsou objekty. Co je na tom tak složitého?

...V těchto aplikacích má použití dědičnosti s hlubokou polymorfní hierarchií hodně dobrý smysl. Naopak mi není moc jasné, proč se data v informačním systému snažit modelovat pomocí objektů a následně se hádat o různé aspekty OOP, když by lépe posloužil relační databázový model. Zvlášť, když data jsou už často v relační databázi uložena.

Proč si myslíte, že vizuální komponenty jsou nějak vhodnější nebo lepší pro OOP než nevizuální? Nevyplývá to z původní popularizátorské představy, že když je něco vidět, tak je to objekt?
Jak zrealizujete v relačním modelu oddělení podproblému (v OOP řešeno zapouzdřením)? Odpovím si sám. Nijak. Relační model patří do skupiny modelů "kámen mrdá cihlu", tj. každý s každým, a to se ještě nebavíme o práci se seznamy.
Název: Re:Dědičnost dnes
Přispěvatel: v 17. 01. 2017, 13:52:42
...Např. GUI toolkity používají OOP již desítky let...Dokonce k tomu nepotřebují ani OO jazyk (GTK+)...

Buďto jazyk konstrukce OOP umí, pak umí vytvářet objekty a je objektový, nebo je neumí, pak to nejsou objekty. Co je na tom tak složitého?
není to složité, OO jazyk a OO programování jsou různé věci a navzájem se nepotřebují, říct o C, že je objektový jazyk, by znělo přece jenom divně
Název: Re:Dědičnost dnes
Přispěvatel: bob 17. 01. 2017, 13:58:41
není to složité, OO jazyk a OO programování jsou různé věci a navzájem se nepotřebují, říct o C, že je objektový jazyk, by znělo přece jenom divně

Dokonce existuje i knihovna pro C (http://libcello.org/, ale nemam zkusenost), ktera prinasi objekty a tady je link na knihu, kde se o tom pise: https://www.cs.rit.edu/~ats/books/ooc.pdf

Nicmene je asi pohodlnejsi mit podporu OO primo v jazyce a ne si to hlidat sam nad strukturama.
Název: Re:Dědičnost dnes
Přispěvatel: Kamil Podlešák 17. 01. 2017, 14:04:49
Proč si myslíte, že vizuální komponenty jsou nějak vhodnější nebo lepší pro OOP než nevizuální? Nevyplývá to z původní popularizátorské představy, že když je něco vidět, tak je to objekt?
Ne. Vizuální komponenty se uvádějí jako příklad úspěšné aplikace OOP z toho důvodu, že se tato kombinace reálně osvědčila a přinesla skutečné výsledky (ulehčení a zjednodušení práce, vyšší produktivitu).
Myslím že na to existují dokonce reálná data, ale ruku do ohně bych za to nedal.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 17. 01. 2017, 14:39:22
Buďto jazyk konstrukce OOP umí, pak umí vytvářet objekty a je objektový, nebo je neumí, pak to nejsou objekty. Co je na tom tak složitého?

S tím bych moc nesouhlasil. Objektové paradigma se dá realizovat různě - viz Java vs. Smalltalk vs. Common Lisp. "Objekt" je abstraktní pojem a jeho konkrétní implementace v tom kterém jazyce je věcí jinou. Nadto i ten abstraktní pojem znamená i v těch výše jmenovaných jazycích pokaždé něco trochu jiného. Objekt v pojetí CLOS se dost liší od Javy i Smalltalku, vlastně je to analogie prachsprostého záznamu a polymorfismu se dosahuje pomocí generických funkcí. Celé je to implementované "jen" v Common Lispu, tedy jazyku neobjektovém. Podobně se dá udělat objektová nadstavba třeba u Forthu. A jako protipříklad bych použil C++, jež sice objekty jakože umí, ale v mých očích to nikdy objektový jazyk nebyl (aby se předešlo různým flamům a nedorozuměním, tak předesílám, že pokud jde o OOP, tak jsem odkojenec Smalltalku).
Podobně např. Assembler je typický špagetový jazyk, ale je-li kompilátor vybaven dobrým makroprocesorem, dá se v něm solidně programovat i strukturovaně.
Takže s pomocí pár procedur a maker bych si asi dokázal napsat cosi, s čím bych mohl vyrábět objekty a programovat objektově i v normálním, neobjektovém C. Ostatně Objective C přesně takto začínalo a přitom jde o rozhodně víc objektový jazyk než C++ (opět v tomto místě raději připomínám svou vazbu na Smalltalk).

A pokud jde o pochopení/nepochopení dědění a jeho praktického používání, tak na základě svých celoživotních zkušeností to vidím zhruba tak, že na papíře v učebnicích to vždycky vypadá všechno krásně jasně, přehledně, elegantně, jakoby tam skoro nebyl žádný problém. Ale když má člověk upravit cizí program, tak musím konstatovat, že myšlenkové pochody, jež vedly zrovna k takové konkrétní hierarchii tříd, jsou mi mnohdy velkou záhadou a logiku celého programu rozhodně neosvětlují, ale spíše zatemňují, a práci rozhodně nešetří, ale přidělávají, protože většinu času netrávím implementací požadované funkcionality, ale přemýšlením, jak to do toho všeho vlastně zašroubovat, aniž bych to musel celé přepsat, nebo aniž bych to tam dobastloval stylem šroub zatlučený kombinačkami.

Základní antagonismus OOP spatřuji v tom, že bylo zamýšleno k zjednodušení a zpřehlednění programu, k usnadnění práce a k zamezení "prasení". Jenže toto vše více-méně funguje jen tehdy, když 80% práce udělá opravdový fachman a ostatní už to jen k sobě skládají (opět, viz Smalltalk nebo třeba COCOA). Pokud na tu zelenou louku přijde psát from scratch objektový program někdo průměrný nebo dokonce podprůměrný, efekt objektového návrhu bude přesně opačný.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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í.
Název: Re:Dědičnost dnes
Přispěvatel: SB 17. 01. 2017, 15:05:03
A není to spíše naopak? Že protected umožňuje horkotěžko vyladěné chování rodičovské třídy nabourat a znepřehlední flow života instance, namísto jednoduchého, přímočarého a hlavně dobře otestovatelného delegování?

Aby tu opět nedošlo k nějakému nedorozumění - kurvení podtřídy ovlivňuje pouze ji a její instance, nadtřídu nijak nabourat nelze.

Protected je ekvivalent public. A jak tu bylo řečeno, nese si problém s tím, že se jedná o veřejné api, které je nutné dodržet. Což zvyšuje komplexitu.

Specializaci, kterou byste místo překrýváním chtěl řešit opačnou závislostí, např. uzávěrami nebo vzorem Strategy, má taky nějaké rozhraní, které u nemůžete změnit, jak vás napadne, takže mi to přijde stejně složité.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: spasitel 17. 01. 2017, 15:46:02
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 17. 01. 2017, 15:57:26
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite

Jako navnada na flame dost ubohe.
Název: Re:Dědičnost dnes
Přispěvatel: spasitel 17. 01. 2017, 15:58:54
zadna navnada. jde o holy fakt a krutou pravdu.
Název: Re:Dědičnost dnes
Přispěvatel: v 17. 01. 2017, 16:02:07
zadna navnada. jde o holy fakt a krutou pravdu.
je to blbost, všichni ví, že nejlepší je java
Název: Re:Dědičnost dnes
Přispěvatel: abc 17. 01. 2017, 16:05:43
Je mi divne, ze tu chybi hlavni lopata... co se stalo?
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 17. 01. 2017, 16:26:27
A jak teda obecně řešit problém, kdy mám třeba 5 různých typů dat, které trochu spolu souvisí, ale dědičnost tam nejde použít přesně proto, co jsi napsal. 5 různých tříd nesdílejích nic? 5 různých služeb pracující s nimi? Nebo použít pro služby generickou službu? A co ukládání? Je to obecně složité téma, ale jen tak jestli máš nějaké tipy k tomu. Málo dat a hodně logiky je jednodušší, ale když jsou data, která je potřeba mít, tak se to komplikuje.

Co je to "trochu souvisejí"?
Jestli ty entity nemají spolu (skoro) nic společného, tak je přece nebudu modelovat dohromady, protože nemají co sdílet, pak budou extra, jejich zpracování jinde bude extra a i způsob ukládání bude extra. I entity, které mají hodně společného, je možno klidně modelovat extra, ale přiděláte si tím práci.

Že mají třeba 5 atributů stejných a dva jiné :) Takže jsou v podstatě stejné, ale "nedává" smysl je modelovat dohromady. Zase z hlediska údržby chce člověk mít co nejvíce společného. Pak přichází na řadu ukládání. Radši bych to ukládal úplně stejně pro obě. Ono každé má něco a chápu, že neexistuje jen jedno řešení.

Takže tvůj nápad je mít zvášť třídy, zvlášt služby a třeba zvlášť ukládání. Což bude asi docela dost duplicity. Pokud tomu dobře rozumím.

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.

Super, díky za info. Všechny příspěvky čtu, jen ne vždy reaguju.

Je mi divne, ze tu chybi hlavni lopata... co se stalo?

Asi nedostal vycházky :D
Název: Re:Dědičnost dnes
Přispěvatel: JS 17. 01. 2017, 16:56:28
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.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: JS 17. 01. 2017, 17:28:06
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.
Název: Re:Dědičnost dnes
Přispěvatel: JS 17. 01. 2017, 17:37:26
Nebo jinak to reknu: Koncept dedeni samotnych funkci (nikoli metod vazanych k nejakemu datovemu typu) nedava velky smysl, snad jedine pokud by slo o zuzeni definicniho oboru (ale proc by to nekdo delal?). V ostatnich pripadech by se porusil LSP.
Název: Re:Dědičnost dnes
Přispěvatel: JS 17. 01. 2017, 17:43:45
Ah, chyba, pri dedeni by muselo jit o rozsireni definicniho oboru, aby se neporusil LSP.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: JS 17. 01. 2017, 18:51:52
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.
Název: Re:Dědičnost dnes
Přispěvatel: anonym 17. 01. 2017, 20:11:55
Ctverec dedi obdelni je typicky priklad OOP hovna, diky za něj. Mohlo by se to jmenovat OOP Shit
Rectangle Paradox.

Já tady jako jediný nebudu říkat, jestli čtverec dědí odbelník nebo ne - to totiž vůbec není nějak předem dáno. Prostě není. Čtverec dědí v naší aplikaci obdelník - a říkám v naší aplikaci, protože v reálném světě takovéhle sračky neřešíme - právě v případě, kdy to SPLŇUJE ÚČEL. Není žádné apripori sračka pravidlo (díky bohu), jestli čtverec dědí obdelník, ikdyž je čtverec brán jako případ obdelníku.

Někdo totiž může říct, že obdelník může být speciální případ cltverce. Máš čtverec, hodíš na něj botu a je z něho obdelník.

Kd říká že je to tak či onak, sám je nerozumí OOP, viz Zboj.
Název: Re:Dědičnost dnes
Přispěvatel: anonym 17. 01. 2017, 20:22:22
Protože kupříkladu indiáni z kmene Pičujů berou zásadně čtvrerec jakožto případ kosodelníku, neboť podle jejich víry z kosodelníku dědí všechno, výjma obdelníku. Obdelník se u nich navíc nesmí používat v jiný den, než o Slunovratu, proto by ho žádný chytrý Pičuj programátor nikde neimplementoval do aplikace, neboť by se mohla spouštět jen jednou do roka.
Název: Re:Dědičnost dnes
Přispěvatel: . 17. 01. 2017, 20:53:28
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.
To není tak úplně pravda, vnořený (embeded) typ si sebou samozřejmě bere všechny metody a lze je používat v rámci vnějšího (outer) typu.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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".
Název: Re:Dědičnost dnes
Přispěvatel: anonym 17. 01. 2017, 21:34:24
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".

Najde se i blb schopen tvrdit, že jistojistě je tomu tak právě naopak.
Název: Re:Dědičnost dnes
Přispěvatel: anonym 17. 01. 2017, 21:39:06
A hele, nějaký chytrý pán se nachazí rovněž i na stackoverflow... nebyl jsem to náhodou já?

http://stackoverflow.com/questions/1030521/is-deriving-square-from-rectangle-a-violation-of-liskovs-substitution-principle
Název: Re:Dědičnost dnes
Přispěvatel: . 18. 01. 2017, 00:20:32
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.
 
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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 (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í.
Název: Re:Dědičnost dnes
Přispěvatel: anonym 18. 01. 2017, 00:42:20
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 (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í.

Haha, jak mě zboj ignoruje.

Dědičnost není svazující, to ty se svazuješ, přechytračils ses. To se ani nedivím, že máš pořád něco proti Javě, když tě přepere i dědičnost  8)
Název: Re:Dědičnost dnes
Přispěvatel: lojzik 18. 01. 2017, 06:36:17
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.
no, on je čtverec i speciálním případem pravidelného mnohoúhelníku (s n=4), což už je ale úplně jiný strom dědičnosti, ve kterém žádný jiný čtyřúhelník není
Název: Re:Dědičnost dnes
Přispěvatel: noef 18. 01. 2017, 07:25:03
Já tady jako jediný nebudu říkat, jestli čtverec dědí odbelník nebo ne - to totiž vůbec není nějak předem dáno. Prostě není. Čtverec dědí v naší aplikaci obdelník - a říkám v naší aplikaci, protože v reálném světě takovéhle sračky neřešíme - právě v případě, kdy to SPLŇUJE ÚČEL. Není žádné apripori sračka pravidlo (díky bohu), jestli čtverec dědí obdelník, ikdyž je čtverec brán jako případ obdelníku.

Tohle je ten pristup nahodneho dedeni pro deduplikaci kodu, ze? Zmeni se jeden detail a cela hierarchie trid se musi zahodit/prekopat, protoze to nikdy nebylo logicky navrzeno.

Někdo totiž může říct, že obdelník může být speciální případ cltverce. Máš čtverec, hodíš na něj botu a je z něho obdelník.

Kd říká že je to tak či onak, sám je nerozumí OOP, viz Zboj.

Zboj alespon pusobi, na rozdil od vetsiny, ze ma i nejaky teoreticky background a prehled o jinych jazycich nez jen Java/C#.

BTW: Dedeni obecne samo o sobe neimplikuje sub-typing ("is-a" vazbu) a pokud vim, tak je mozne v potomcich cleny i odebirat, takze pomoci obecneho dedeni lze modelovat i ten ctverec<->obdelnik jakymkoliv smerem bez zbytecnych clenu (pochopitelne to pak nesplnuje LSP, pokud se teda napouziji nejake interfacy spolecne pro obe tridy).
Název: Re:Dědičnost dnes
Přispěvatel: liewyec 18. 01. 2017, 09:06:11
Spis vidim problem v dedicnosti v tom, ze misto aby se definovalo rozhrani tridy (v gui treba nastaveni barvy, velikosti, atd.) a to se pak pouzilo pro upravovani objektu(s tim ze by trida dedila interface ciste pro definovani funkci spolecnych pro pribuzne tridy(zase v gui treba render), tak jsou nekteri "experti" schopni pouzivat dedicnost tak, ze misto toho majidefinovanou funkci ktera ma za parametr odkaz data, ze kterych si ta trida ty informace ziska. Takze pokud pak potrebuji z tech dat ziskat neco jineho tak pouziji dedicnost a predefinuji funkci, ketere se pradava odkaz na data. Pak maji spoustu trid, ktere jsou v podstate uplne stejne. Coz vede naopak k duplikaci kodu, duplikaci dat, spouste ptomku jedne zakladni tridy, debilne se s tim pracuje a ma to spoustu dalsich problemu.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 09:28:15
...Smaltalk má objekt, a ty ho vždycky přetěžuješ - to je sice hezký, ale s tím poděděným chováním si zároveň podědil i všechny ty vztahy. Což u typovaného jazyka může bejt dost problém. Další problém je v tom, že čím delší linie, tím méně se člověku chce opravovat chybné chování předka. Což je trapné.

Pozor na ten termín "přetěžování", s OOP nesouvisí, měl jste na mysli "překrývání".
Vzhledem k tomu, že dědím z důvodu příbuznosti, zdědění vztahů je logické a nevadí. S typovostí jazyku souvislost nevidím.
Oprava předka opraví i dědice, to je přece žádoucí.

...druhak máš trait/mixin... Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

Mixin bych pochopil, ale trait zavání 1. funkcionálním programováním, které odděluje data a zpracování, což je v přesném protikladu k OOP, 2. anemickým datovým modelem. Chování je v OOP z dobrého důvodu pevně spojeno se stavy, jejich rozdělení tudíž nemá smysl.

...Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.

Specializace platí, a to ve všem, tj. stavy i chování.
Většina vývojářů neumí ani pochopit OOP, budeme ho kvůli tomu rušit jako koncept na prd?
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 18. 01. 2017, 09:36:55
Citam tak tuto diskusiu a zaujala ma jedna vec. Co myslite pod pojmom "skladani"? Mozete uviest priklad prosim? Dakujem
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 09:40:30
...
Kód: [Vybrat]
Hrnek dědí Nádoba
Sklenice dědí Nádoba

Voda dědí Náplň
Hrách dědí Náplň

Nádoba agreguje Náplň
or.

Určitě je to k zamyšlení...
Otázkou je, proč zobecňovat hrnek a sklenici na nádobu, co s tím budu dělat.
Náplně jsou dle mě chybně, protože to, že něco do něčeho můžu dát, tomu ještě nedává nějaké vlastnosti, to je jakési specifické použití, takže zobecněním vody a hrachu určitě není náplň.
Název: Re:Dědičnost dnes
Přispěvatel: noef 18. 01. 2017, 09:42:23
...
...druhak máš trait/mixin... Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

Mixin bych pochopil, ale trait zavání 1. funkcionálním programováním, které odděluje data a zpracování, což je v přesném protikladu k OOP, 2. anemickým datovým modelem. Chování je v OOP z dobrého důvodu pevně spojeno se stavy, jejich rozdělení tudíž nemá smysl.
...

Myslim, ze tohle pro traity napr. ve Scale neplati. Trait si muze urcit do ceho bude namixovan (v podstate interface "this") a muze obsahovat jak stav, tak zpracovani. Casto tak rozdeluji velke tridy do nekolika traitu (a souboru) kvuli prehlednosti.

Po pravde si myslim, ze pokud ve Scale jedete "vice FP", tak spise pouzivate case classy a traity maximalne jako rozhrani (z case class nelze dedit dalsi case class). Traity si myslim jsou vice uzitecne pro OOP nez FP, alespon ve Scale.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 09:44:34
...protoze spoustu casu travite usilim navrhnout smysluplnou hierarchii, i kdyz to nema smysl.

Vždy můžete zůstat u placaté hierarchie, dědit ve vašem modelu nemusíte, akorát si musíte ujasnit, zda vám to práci přidá nebo ubere.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 09:46:16
...Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.

Platí vše, co pro obdélník, též pro čtverec?
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 09:50:12
Koukam, ze OOP sice deformuje mysleni, ale relacni pohled na vec ho dava do mixeru.

Z pohledu historie modelování v IT považuju OOP za alespoň částečnou nápravu myšlení, ale s mixérem souhlasím.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 09:58:03
Dokonce existuje i knihovna pro C (http://libcello.org/, ale nemam zkusenost), ktera prinasi objekty a tady je link na knihu, kde se o tom pise: https://www.cs.rit.edu/~ats/books/ooc.pdf

Je jedno, zda jde o možnosti jazyku či knihovny, podstatné je, zda to zvládá klíčové vlastnosti OOP. Pak je to objektový jazyk (akorát s některými to jde jednodušeji).
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 10:29:00
S tím bych moc nesouhlasil. Objektové paradigma se dá realizovat různě...

Jasně, teď bychom se tu mohli hádat, co je to objekt. Nějaké minimum, pod které strukturu za objekt nepovažuju, tu je, pod to tomu nemá smysl říkat objektový jazyk. Mimochodem dědění mezi základní koncepty OOP nepatří.

...že na papíře v učebnicích to vždycky vypadá všechno krásně jasně, přehledně, elegantně, jakoby tam skoro nebyl žádný problém...

Nevypadá. Nepochopení OOP má původ 1. v nedostatku kvalitní literatury. 2. v příkladech na obskurních jazycích, ale to už se tu řešilo.

...většinu času netrávím implementací požadované funkcionality, ale přemýšlením, jak to do toho všeho vlastně zašroubovat, aniž bych to musel celé přepsat, nebo aniž bych to tam dobastloval stylem šroub zatlučený kombinačkami.

Když to nemůžu opravit, tak problém/sračku izoluju a vyřeším uvnitř jednoho objektu/třídy, což je typicky objektový přístup.

Základní antagonismus OOP spatřuji v tom, že bylo zamýšleno k zjednodušení a zpřehlednění programu, k usnadnění práce a k zamezení "prasení". Jenže toto vše více-méně funguje jen tehdy, když 80% práce udělá opravdový fachman a ostatní už to jen k sobě skládají (opět, viz Smalltalk nebo třeba COCOA). Pokud na tu zelenou louku přijde psát from scratch objektový program někdo průměrný nebo dokonce podprůměrný, efekt objektového návrhu bude přesně opačný.

S tím se dá souhlasit, prostě je třeba daný nástroj zvládnout.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 10:35:09
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í.

Ano, virtuální volání, to je z mého pohledu největší rozpor mezi původním OOP (pozdní vazba s přenesením odpovědnosti na cílový objekt) a dnešní implementací (časná vazba s rozhodováním zdrojového objektu řešená typovou kontrolou).
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 10:41:32
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite

Časná vazba, podtypový polymorfismus, dědičnost v třídách pouze na instanční straně, vynucené volání super v konstruktorech, implicitně nevirtuální metody (OOP pojem nevirtuální nezná, protože nedává smysl), poměrně komplikovaná syntraxe, porušení zapouzdření mezi instancemi téže třídy...

To pálím jen tak z hlavy...
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 10:42:48
je to blbost, všichni ví, že nejlepší je java

Java je to samé v bleděmodrém. Ta si může s Ckanálem podat ruku.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 11:01:41
Že mají třeba 5 atributů stejných a dva jiné :) Takže jsou v podstatě stejné, ale "nedává" smysl je modelovat dohromady. Zase z hlediska údržby chce člověk mít co nejvíce společného.

Tak jestli mají stejné nějaké vlastnosti, ale jejich chování je jiné, pak spolu nesouvisejí. Nebo třeba sdílejí společné stavy, které je třeba vyčlenit do jiné třídy.

Pak přichází na řadu ukládání. Radši bych to ukládal úplně stejně pro obě. Ono každé má něco a chápu, že neexistuje jen jedno řešení. Takže tvůj nápad je mít zvášť třídy, zvlášt služby a třeba zvlášť ukládání. Což bude asi docela dost duplicity. Pokud tomu dobře rozumím.

Když budete ukládat pouze stavy (typické pro dnešní DB) stejného formátu různých tříd jedním ukládačem, tak je to 1. systematická chyba, 2. se vám to při jakékoliv změně jedné ze tříd rozesere. Takže každá třída svoje.
Služba je buďto vlastností objektu, nebo patří jinam, pak je třeba si ještě uvědomit závislost co na čem.
Ukládání (persistence) modelu (objektu) je VŽDY extra, protože s modelem nesouvisí - lze přece ukládat na různá zařízení (DB, soubor, HTTP, paměť(!), ...), na víc současně nebo to za běhu prohazovat...
Název: Re:Dědičnost dnes
Přispěvatel: spasitel 18. 01. 2017, 12:42:27
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite

Časná vazba, podtypový polymorfismus, dědičnost v třídách pouze na instanční straně, vynucené volání super v konstruktorech, implicitně nevirtuální metody (OOP pojem nevirtuální nezná, protože nedává smysl), poměrně komplikovaná syntraxe, porušení zapouzdření mezi instancemi téže třídy...

To pálím jen tak z hlavy...
no jo to palite, ale asi slepima. ono jako jo, mozna jsou i lepsi OOP jazyky (Smalltalk), jenom C#, Java, C++, vyuziva vetsina vyvojaru, takze o cem je rec? hlavni je, nech je kod citelnej a dobre udrzovatelnej. nemusi se striktne dodrzovat pravidla. jako v teoreticke rovine si muzete tady na rootu pokecat, to je tak vse.
Název: Re:Dědičnost dnes
Přispěvatel: balki 18. 01. 2017, 13:08:00
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?

Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 18. 01. 2017, 13:35:24
ked je tu tato tema, tak sa spytam, ako by ste riesili nasledujucu situaciu:

mate viacero obrazoviek a kazda ma vlastnu triedu. na hociakej obrazovke moze prist callback ConnectionChanged a vy nan potrebujete reagovat. Riesili by ste to ze, spravite base triedu a kazdu triedu pre danu obrazovku odvodite od tejto base triedy? alebo by ste v kazdej obrazovkovej triede implementovali logiku, v podstate vsade tu istu, ked by sa vyvolalo ConnectionChanged?
Název: Re:Dědičnost dnes
Přispěvatel: balki 18. 01. 2017, 13:45:28
ked je tu tato tema, tak sa spytam, ako by ste riesili nasledujucu situaciu:

mate viacero obrazoviek a kazda ma vlastnu triedu. na hociakej obrazovke moze prist callback ConnectionChanged a vy nan potrebujete reagovat. Riesili by ste to ze, spravite base triedu a kazdu triedu pre danu obrazovku odvodite od tejto base triedy? alebo by ste v kazdej obrazovkovej triede implementovali logiku, v podstate vsade tu istu, ked by sa vyvolalo ConnectionChanged?

Na  by bolo velmi vyhodne pouzit traity tak, ako su implementovane v scale. Tu spolocnu logiku by som tam "prilepil", aby zbytocne nezatazovala hierarchiu dedicnosti.  Ak by neboli traity, riesil by som to podla situacie.
Název: Re:Dědičnost dnes
Přispěvatel: Polymath 18. 01. 2017, 13:46:20
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?

Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.
Doktorát z čeho? Historie "starých Slováků"? Podle toho, jak tu trolíš, nemáš ani základku a někde v Horních Uhrách se opíráš o lopatu a v jednom kuse nasáváš borovičku. Tak nás všechny ušetř těch kravin a dej si odchod.
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 18. 01. 2017, 13:49:49
ked je tu tato tema, tak sa spytam, ako by ste riesili nasledujucu situaciu:

mate viacero obrazoviek a kazda ma vlastnu triedu. na hociakej obrazovke moze prist callback ConnectionChanged a vy nan potrebujete reagovat. Riesili by ste to ze, spravite base triedu a kazdu triedu pre danu obrazovku odvodite od tejto base triedy? alebo by ste v kazdej obrazovkovej triede implementovali logiku, v podstate vsade tu istu, ked by sa vyvolalo ConnectionChanged?

Na  by bolo velmi vyhodne pouzit traity tak, ako su implementovane v scale. Tu spolocnu logiku by som tam "prilepil", aby zbytocne nezatazovala hierarchiu dedicnosti.  Ak by neboli traity, riesil by som to podla situacie.
dajme tomu ze to riesime v C#
Název: Re:Dědičnost dnes
Přispěvatel: balki 18. 01. 2017, 13:53:11
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?

Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.
Doktorát z čeho? Historie "starých Slováků"? Podle toho, jak tu trolíš, nemáš ani základku a někde v Horních Uhrách se opíráš o lopatu a v jednom kuse nasáváš borovičku. Tak nás všechny ušetř těch kravin a dej si odchod.

Odbor softverove inzinierstvo, zoberal som sa symetrickym aspektovo-orientovanym programovanim. Vy nadavate ako xenofobny dlazdic ;)  Osobne nemam len rad ludi, co sa premudrelo vyjadruju, aby robili dojem, a pritom povedia to iste. To je cele.
Název: Re:Dědičnost dnes
Přispěvatel: gll 18. 01. 2017, 13:55:14
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?

Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.

Možná doktorát z nějaké pseudovědy. Napadáte kde co bez nějakého racionálního odůvodnění.
Název: Re:Dědičnost dnes
Přispěvatel: balki 18. 01. 2017, 13:58:21
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?

Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.

Možná doktorát z nějaké pseudovědy. Napadáte kde co bez nějakého racionálního odůvodnění.

Skor to citim naopak. Uz urcite viete, ze pseudoveda a viete co som povedal, aj ked vytrhavate z kontextu.
Název: Re:Dědičnost dnes
Přispěvatel: Logik 18. 01. 2017, 14:07:42
Doufám, že to sem nikdo nedal (nepročet jsem vše), ale nabídnu jiný pohled na čtverec a obdélník:

Obdélník je speciální typ čtverce, protože je to čtverec, který umí totéž, co čtverec, ale navíc umí měnit poměr svých stran.

A teď mě sežerte :-)
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 18. 01. 2017, 14:11:36
ked je tu tato tema, tak sa spytam, ako by ste riesili nasledujucu situaciu:

mate viacero obrazoviek a kazda ma vlastnu triedu. na hociakej obrazovke moze prist callback ConnectionChanged a vy nan potrebujete reagovat. Riesili by ste to ze, spravite base triedu a kazdu triedu pre danu obrazovku odvodite od tejto base triedy? alebo by ste v kazdej obrazovkovej triede implementovali logiku, v podstate vsade tu istu, ked by sa vyvolalo ConnectionChanged?
??

a co poviete na tuto knizku? oplati sa?
https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?s=books&ie=UTF8&qid=1484744799&sr=1-1&keywords=object+oriented+programming (https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?s=books&ie=UTF8&qid=1484744799&sr=1-1&keywords=object+oriented+programming)
Název: Re:Dědičnost dnes
Přispěvatel: Polymath 18. 01. 2017, 14:14:05
Doufám, že to sem nikdo nedal (nepročet jsem vše), ale nabídnu jiný pohled na čtverec a obdélník:

Obdélník je speciální typ čtverce, protože je to čtverec, který umí totéž, co čtverec, ale navíc umí měnit poměr svých stran.

A teď mě sežerte :-)
To je blbost. Každý čtverec je obdélník, ale ne naopak.
Název: Re:Dědičnost dnes
Přispěvatel: Logik 18. 01. 2017, 14:15:47
Ano? Každý čtverec je prostorový útvar, jehož obsah jde parametrizovat pomocí dvou NEZÁVISLÝCH proměnných? Protože to přesně obdélník (MIMO JINÉ) je...

Název: Re:Dědičnost dnes
Přispěvatel: balki 18. 01. 2017, 14:15:50
ked je tu tato tema, tak sa spytam, ako by ste riesili nasledujucu situaciu:

mate viacero obrazoviek a kazda ma vlastnu triedu. na hociakej obrazovke moze prist callback ConnectionChanged a vy nan potrebujete reagovat. Riesili by ste to ze, spravite base triedu a kazdu triedu pre danu obrazovku odvodite od tejto base triedy? alebo by ste v kazdej obrazovkovej triede implementovali logiku, v podstate vsade tu istu, ked by sa vyvolalo ConnectionChanged?
??

a co poviete na tuto knizku? oplati sa?
https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?s=books&ie=UTF8&qid=1484744799&sr=1-1&keywords=object+oriented+programming (https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?s=books&ie=UTF8&qid=1484744799&sr=1-1&keywords=object+oriented+programming)

Urcite sa oplati. Tu knizku je vhodne citat tak, ze sa clovek uci principy vzorov a nie rovno tie implementacie.  A tiez kriticky treba si zhodnotit, ci vzory uz nie su implementovane nejakymi konstrukciami priamo v jazyku.

Pre vasu otazku je tam vzor observer.
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 18. 01. 2017, 14:34:27
ja som to implementoval v style:

Kód: [Vybrat]
public class Base {
 
   public void ConnectionChanged() {}

}

public class Class1 : Base
{
    private Obj1 _field;

    public Class1(){
      _field = Factory.Get(IObj1);
      _field.ConnectionChanged += OnConnectionChanged;
    }

     private void OnConnectionChanged() {  base.ConnectionChanged; }
}

Název: Re:Dědičnost dnes
Přispěvatel: lojzik 18. 01. 2017, 14:49:15
Ano? Každý čtverec je prostorový útvar, jehož obsah jde parametrizovat pomocí dvou NEZÁVISLÝCH proměnných? Protože to přesně obdélník (MIMO JINÉ) je...
a ta druhá nezávislá proměnná, aby to byl ještě čtverec, je konkrétně která?
Název: Re:Dědičnost dnes
Přispěvatel: v 18. 01. 2017, 14:51:49
Ano? Každý čtverec je prostorový útvar, jehož obsah jde parametrizovat pomocí dvou NEZÁVISLÝCH proměnných? Protože to přesně obdélník (MIMO JINÉ) je...
a ta druhá nezávislá proměnná, aby to byl ještě čtverec, je konkrétně která?
neeeekrrrmiiit :(((
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 14:59:10
To je zase příspěvek...

...OOP (jak se bezne chape, treba v Jave) micha tri koncepty dohromady (zapouzdreni, dedicnost, polymorfismus) do jednoho - trid...

Třída není realizátorem zapouzdření, tím je viditelnost metod a vlastností. Třída je realizátorem vytváření objektů.

...dedicnost dava smysl pro data, nikoli pro funkce, a naopak, polymorfismus dava smysl pro funkce, nikoli pro data...

To jako že by se podědilo a všechny metody přepsaly znovu? Čeho by se tím dosáhlo?
Polymorfismus je zprostředkován protokolem objektu, na vnitřní struktuře metod a stavů je nezávislý.
Název: Re:Dědičnost dnes
Přispěvatel: SB 18. 01. 2017, 15:00:28
...Treba jazyk Go ma take ty tri koncepty rozdelene, a dedeni dat (a jen dat!) tam jde delat pomoci vnorene struktury...

A nemá to s děděním v OOP společný jen název?
Název: Re:Dědičnost dnes
Přispěvatel: Cikada_ 18. 01. 2017, 15:36:08
Ano? Každý čtverec je prostorový útvar, jehož obsah jde parametrizovat pomocí dvou NEZÁVISLÝCH proměnných? Protože to přesně obdélník (MIMO JINÉ) je...

Odkdy je čtverec (či obdélník)  prostorový útvar??!!! Zpátky na základku! (Proč mluvíte o obsahu?? Proč o dvou nezávislých proměnných?? Mimochodem to, že velikost strany a je stejná jako velikost strany b neznamená, že jsou to nějaké závislé proměnné. Tohle jsou základy matematiky, to by měl každý programátor znát!)

Čtverec je speciální případ obdélníku, který má shodou okolností všechny strany stejně dlouhé. Tečka. Tohle se učí na ZŠ...
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 18. 01. 2017, 16:00:00
Ono strasne zalezi na tom, zda chceme mit instance mutable nebo imutable a co s nimi dal. U imutable je celkem bezproblemove mit ctverec jako specialni obdelnik (jenom je tam jaksi jedna clenska promenna b jako pate kolo u vozu). Ale u mutable to zacne byt o neco horsi - setB(...) by asi nemelo mit v kontraktu, ze meni i a nebo ze vyhodi vyjimku.
A opacny smer dedeni samozrejme narazi na LSP daleko tvrdeji.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 18. 01. 2017, 16:28:25
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.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 18. 01. 2017, 16:42:52
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.

No to je zase zjisteni, ze skolni problem nepotkavas v praxi...

Ten specialni konstruktor je presne to reseni, ktere muze a nemusi fungovat. A prave proto je dobre o tom premyslet.
Název: Re:Dědičnost dnes
Přispěvatel: Inkvizitor 18. 01. 2017, 16:44:00
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.

Pravdu bohuzel (bohudik!) nema. Pojem "ctverec" definovany jako obdelnik, ktery ma vsechny strany stejne dlouhe, je pro dany ucel na houby. Tudiz ctverec IS A PRAVOUHELNIK, ktery ma vsechny strany stejne dlouhe a obdelnik IS A PRAVOUHELNIK, ktery ma dve rovnobezne strany stejne dlouhe a ostatni dve strany take stejne dlouhe. Nema smysl se bavit o implementaci, kdyz se vychazi ze spatneho popisu sveta.

Kdyz si tohle uvedomim, muzu hledat cestu, jak pripadne vyresit problem obdelnika, ktery nesmi z definice mit vsechny strany stejne dlouhe (pokud nam to fakt vadi). A resit to samozrejme obecne jde.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 18. 01. 2017, 17:49:29
Ten specialni konstruktor je presne to reseni, ktere muze a nemusi fungovat. A prave proto je dobre o tom premyslet.
Č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.

Protože záleží na tom konkrétním problému. A právě proto mi připadá tahle dogmatická disputace o jednom spíše filosofickém podproblému, jenž by hypoteticky někdy mohl být součástí nějakého nadproblému, tak nějak zbytečná. Podstatný je ten hlavní problém.
Jsou případy, kdy nějaký speciální konstruktor v rámci obdélníku bude vhodný, a kdy nikoli. Půjde-li o šetření pamětí, tak sice speciální třídu pro čtverec zavedu, ale rozhodně ji nebudu odvozovat od obdélníku. Dovedu si představit řešení pomocí sdružených tříd (aka abstract factory) či s pomocí změny třídy, nebo něco úplně jiného, zkrátka podle potřeby řešeného problému, ne podle toho, že se čtverec odvodit od obdélníku. Což je přesně to, co se při objektovém návrhu často děje, tj. že se něco zavádí jen proto, že to jde a že má někdo pocit, že by to tak mělo být, a ne proto, že to je k něčemu dobré.
Na tomto problému je dobré jen to, že je vidět, že v různých situacích se hodí různá řešení a recept na to jediné správné prostě bez znalosti dalšího kontextu není.
Název: Re:Dědičnost dnes
Přispěvatel: MartinBeran 18. 01. 2017, 18:01:09
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í.

Ano, virtuální volání, to je z mého pohledu největší rozpor mezi původním OOP (pozdní vazba s přenesením odpovědnosti na cílový objekt) a dnešní implementací (časná vazba s rozhodováním zdrojového objektu řešená typovou kontrolou).

Co to je "původní OOP"? Něco ještě před Simulou? Protože pojetí tříd, objektů, dědičnosti a virtuálních funkcí v jazyce Simula 67 je blíž dnešním jazykům jako C++ nebo Java, než Smalltalku, který vznikl až po Simule.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 18. 01. 2017, 18:07:36
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í.

Ano, virtuální volání, to je z mého pohledu největší rozpor mezi původním OOP (pozdní vazba s přenesením odpovědnosti na cílový objekt) a dnešní implementací (časná vazba s rozhodováním zdrojového objektu řešená typovou kontrolou).

Co to je "původní OOP"? Něco ještě před Simulou? Protože pojetí tříd, objektů, dědičnosti a virtuálních funkcí v jazyce Simula 67 je blíž dnešním jazykům jako C++ nebo Java, než Smalltalku, který vznikl až po Simule.

Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.
Název: Re:Dědičnost dnes
Přispěvatel: MartinBeran 18. 01. 2017, 18:19:31
Odkdy je čtverec (či obdélník)  prostorový útvar??!!! Zpátky na základku! (Proč mluvíte o obsahu?? Proč o dvou nezávislých proměnných?? Mimochodem to, že velikost strany a je stejná jako velikost strany b neznamená, že jsou to nějaké závislé proměnné. Tohle jsou základy matematiky, to by měl každý programátor znát!)

Vhodná definice pojmu (resp. třídy) čtverec se může v závislosti na kontextu dost lišit. Dovedu si představit problémy, pro které se hodí snad všechny varianty třídy Čtverec a jejích vztahů k třídě Obdélník, které zde byly zmíněny. A pokud bude Čtverec součástí množiny tříd pro reprezentaci 3D scény, může být chápán jako prostorový útvar odvozený z Kružnice (která je odvozená z třídy Bod). Zároveň může být Čtverec bázovou třídou pro obdélník i krychli.

Čtverec je speciální případ obdélníku, který má shodou okolností všechny strany stejně dlouhé. Tečka. Tohle se učí na ZŠ...

...a teprve v matematických předmětech na vysoké škole se člověk dozví, že ty "pravdy" ze ZŠ jsou většinou zjednodušení platná jen za specifických podmínek.
Název: Re:Dědičnost dnes
Přispěvatel: MartinBeran 18. 01. 2017, 18:31:50
Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 18. 01. 2017, 19:03:19
Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

Řeč byla o tom, co to je "původní OOP". Pojem OOP použil poprvé Alan Kay, a to v souvislosti se Smalltalkem. Byl jsi to ty, kdo tu začal slovíčkařit o tom, co to je "původní OOP". Řekl bych, že my ostatní tak nějak chápeme, že OOP zahrnuje více konceptů (sám jsem to tu už zmínil). A proto odkazuje-li někdo na ten smalltalkovský, tak obrat "původní OOP" je tedy zcela na místě a srozumitelný. I z toho důvodu, že narozdíl od Simuly se Smalltalk jako první objektový jazyk začal používat i v praxi a používá se dodnes.
Že se Smalltalk inspiroval (mimo jiné) i Simulou tu nikdo nezpochybňuje. Ale protestanti tu jsou taky až od Luthera, přestože se inspirovali (mimo jiné) i husity. Ačkoli jsou husité dnes často řazeni mezi protestantská hnutí, tak hovořit o nich jako o "původních protestantech" by bylo přinejmenším zavádějící.
Název: Re:Dědičnost dnes
Přispěvatel: JS 18. 01. 2017, 19:14:39
Třída není realizátorem zapouzdření, tím je viditelnost metod a vlastností. Třída je realizátorem vytváření objektů.

Nejsem si jisty, co tim chces rict. Co ja chci rict je, ze zapouzdreni lze treba v Jave realizovat dvema zpusoby - viditelnosti v ramci tridy a viditelnosti v ramci modulu (package). Ale k cemu je dobre mit dve varianty stejne abstrakce? Nestacil by na to jen modul? Je to proste neortogonalni navrh jazyka.

Citace
To jako že by se podědilo a všechny metody přepsaly znovu? Čeho by se tím dosáhlo?

Prave ze pri datovem dedeni nemusis nic prepisovat, funkce ktere s temi daty pracuji dokonce ani nemusi byt polymorfni (tedy v ramci typoveho systemu mozna ano, ale ne realne). Coz je taky duvod, proc dedeni dat a polymorfismus jsou dve ruzne veci.

Treba vezmi si to Go - kdyz si definujes strukturu a podedis ji v jine (jenom jednonasobna dedicnost je mozna), tak pak metody (je to uz chvile co jsem se Go ucil, takze jsem to pozapomnel) mohou obdrzet tu zdedenou strukturu misto puvodni, ale to je proto, ze skutecne realne bude pracovat s pointerem na tu strukturu jako kdyby to byl pointer na tu puvodni. Bude stacit jen jedna varianta dane metody, takze ta metoda (vnitrne, nikoli z hlediska typoveho systemu) neni jen polymorfni ve svem argumentu, ale je to doslova ta stejna funkce.

Dedicnost dat je i v nekterych databazich, treba Postgres, ktere dovoluji podedit tabulku a tak ji jakoby rozsirit o ruzne dalsi sloupce. Ted tedy nevim jestli dotaz nad tou puvodni tabulkou zahrnuje i jeji potomky, ale asi ano, jinak by to moc nedavalo smysl.

Citace
Polymorfismus je zprostředkován protokolem objektu, na vnitřní struktuře metod a stavů je nezávislý.

Takze v pripade dedeni dat je to opacne, nez pises - tam se prave vyhneme polymorfismu, ale spolehame na spolecnou strukturu predka. Proto take data (tridy) neni vhodne dedit vicenasobne, protoze vznika problem diamantu (chceme tam tataz data vickrat ze dvou ruznych predku se spolecnym potomkem?), naopak pri dedeni interfacu, coz je zpusob polymorfismu, tenhle problem nevznika.

Z techto duvodu je praktictejsi nad dedenim a polymorfismem uvazovat separatne, nez je kombinovat. Jinak zase vznika vyse problem neortogonalniho navrhu jazyka, treba v Jave museli pridat interfacy (coz je relativne ciste), ktere v podstate castecne duplikuji funkcionalitu trid, ktera je nedostatecna (neni dovolena vicenasobna dedicnost) proto, ze se polymorfismus micha s datovou dedicnosti. (A z toho pak vyplyvaji ruzne zbytecne otazky, moje oblibena je: Kdy je lepsi pouzit interface a kdy abstraktni tridu?)

Citace
A nemá to s děděním v OOP společný jen název?

Prestan se chytat detailu a zamysli se nad tim - jsou to opravdu tri ruzne koncepty, ktere se v tridach smesuji, a trochu pravda problematicka terminologie na tom nic nemeni.
Název: Re:Dědičnost dnes
Přispěvatel: Cikada_ 18. 01. 2017, 20:17:50
Odkdy je čtverec (či obdélník)  prostorový útvar??!!! Zpátky na základku! (Proč mluvíte o obsahu?? Proč o dvou nezávislých proměnných?? Mimochodem to, že velikost strany a je stejná jako velikost strany b neznamená, že jsou to nějaké závislé proměnné. Tohle jsou základy matematiky, to by měl každý programátor znát!)

Vhodná definice pojmu (resp. třídy) čtverec se může v závislosti na kontextu dost lišit. Dovedu si představit problémy, pro které se hodí snad všechny varianty třídy Čtverec a jejích vztahů k třídě Obdélník, které zde byly zmíněny. A pokud bude Čtverec součástí množiny tříd pro reprezentaci 3D scény, může být chápán jako prostorový útvar odvozený z Kružnice (která je odvozená z třídy Bod). Zároveň může být Čtverec bázovou třídou pro obdélník i krychli.

[/quote]

Naneštěstí pro vás nemluvil o o třídě, ale o pojmu čtverec a ten je poněkud jasně vymezený. To, že si to v kódu naprasíte odtrženě od jakékoliv vazby na ten pojem, nic nemění. Čtverec je rovinný útvar a vaše představy na tom nic nezmění. (Upřímně pořád tajně doufám, že jen trollíte...)

Čtverec je speciální případ obdélníku, který má shodou okolností všechny strany stejně dlouhé. Tečka. Tohle se učí na ZŠ...

...a teprve v matematických předmětech na vysoké škole se člověk dozví, že ty "pravdy" ze ZŠ jsou většinou zjednodušení platná jen za specifických podmínek.

Ano, pokud chceme generalizovat. Nicméně bavili jsme se o čtverci, takže bych rád viděl nějaký smysluplný důkaz o tom, že čtverec není rovinným tělesem a není speciálním případem obdélníku (respektive na které vysoké škole vám tvrdili, že toto neplatí? nebo prostě jen plácáte?).
Název: Re:Dědičnost dnes
Přispěvatel: spasitel 18. 01. 2017, 20:48:59
jo panove, co tak si neco precist:

https://www.youtube.com/watch?v=JIhIWHFnHAQ
http://mathcentral.uregina.ca/qq/database/qq.09.07/h/odette1.html (https://www.youtube.com/watch?v=JIhIWHFnHAQ
http://mathcentral.uregina.ca/qq/database/qq.09.07/h/odette1.html)
Název: Re:Dědičnost dnes
Přispěvatel: kutr 19. 01. 2017, 06:48:30
Nad "programátorskými" diskuzemi na rootu nezbývá než kroutit hlavou. Z toho by se skoro dal založit nový lamer. Jenom doufám, že nikdo z vás neprogramuje a jen si honíte ego v diskuzi.
Název: Re:Dědičnost dnes
Přispěvatel: n 19. 01. 2017, 07:34:29
...Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.

Platí vše, co pro obdélník, též pro čtverec?

No ctverec je specialni pripad obedlniku, ktery ma stejne hrany. Nicmene obdelnik muze mit ruzne dlouhe hrany, narozdil od ctverce, ktery nesmi mit ruzne dlouhe hrany, protoze by pak nebyl ctvercem. Pokud tedy mas moznost menit hrany, tak je tento rozpor problematicky. Je otazka pohledu co s tim bude clovek delat. Jak uz nekdo psal, je treba navrhovat podle ucelu. Problem je, ze ucel se casto muze zmenit,  casem nekdo prijde a zmeni pozadavky na system, coz muze vest k celemu prepisu vseho, nebo k ruznym ochcavkam. Pri vyvoji je casto potreba najit nejaky kompromis mezi prilis komplikovanym a robustnim navrhem(ktery stejne nemusi stacit, protoze v budoucnu nekdo nastavi nejaky "absurdni pozadavek" na system) a mezi slepenym hovnem, ktere je uplne nahouby jeste driv, nez je system dokonceny.
Název: Re:Dědičnost dnes
Přispěvatel: MartinBeran 19. 01. 2017, 09:56:12
Řeč byla o tom, co to je "původní OOP". Pojem OOP použil poprvé Alan Kay, a to v souvislosti se Smalltalkem. Byl jsi to ty, kdo tu začal slovíčkařit o tom, co to je "původní OOP". Řekl bych, že my ostatní tak nějak chápeme, že OOP zahrnuje více konceptů (sám jsem to tu už zmínil). A proto odkazuje-li někdo na ten smalltalkovský, tak obrat "původní OOP" je tedy zcela na místě a srozumitelný.

Na tom, že OOP zahrnuje více konceptů, se shodneme. Jeden z těch konceptů je implementován v jazyce Smalltalk, jiný v C++ a Javě. Ten druhý pochází ze Simuly, která vznikla před Smalltalkem. Já jsem výraz "původní OOP" pochopil jako "první v čase", nikoliv "co bylo jako OOP poprvé nazvané". Přijde mi, že možné jsou v češtině oba významy. Stačí vyjasnit si nedorozumění a věcně odpovědět na otázku...
Název: Re:Dědičnost dnes
Přispěvatel: Inkvizitor 19. 01. 2017, 10:21:13
Nad "programátorskými" diskuzemi na rootu nezbývá než kroutit hlavou. Z toho by se skoro dal založit nový lamer. Jenom doufám, že nikdo z vás neprogramuje a jen si honíte ego v diskuzi.

Ja bych zase byl radeji, kdyby cast lidi, kteri do teto diskuse prispeli, byla vzorem pro ostatni "programatory". Lepicu bez mozku je na trhu vice nez dost.
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 10:33:46
Nad "programátorskými" diskuzemi na rootu nezbývá než kroutit hlavou. Z toho by se skoro dal založit nový lamer. Jenom doufám, že nikdo z vás neprogramuje a jen si honíte ego v diskuzi.

Ja bych zase byl radeji, kdyby cast lidi, kteri do teto diskuse prispeli, byla vzorem pro ostatni "programatory". Lepicu bez mozku je na trhu vice nez dost.
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 19. 01. 2017, 10:56:24
ja som sa nieco pytal a na mna sa s prepacenim vysrali. hlavne ze riesili stvorce a obdlzniky. a pytal som sa len na radu
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 11:20:43
ja som sa nieco pytal a na mna sa s prepacenim vysrali. hlavne ze riesili stvorce a obdlzniky. a pytal som sa len na radu

Spytajte sa este raz, ja som imho odpovedal :)
Název: Re:Dědičnost dnes
Přispěvatel: milan:1 19. 01. 2017, 11:32:05
ja som to implementoval v style:

Kód: [Vybrat]
public class Base {
 
   public void ConnectionChanged() {}

}

public class Class1 : Base
{
    private Obj1 _field;

    public Class1(){
      _field = Factory.Get(IObj1);
      _field.ConnectionChanged += OnConnectionChanged;
    }

     private void OnConnectionChanged() {  base.ConnectionChanged; }
}

tak este raz :)
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 12:21:29
Nad "programátorskými" diskuzemi na rootu nezbývá než kroutit hlavou. Z toho by se skoro dal založit nový lamer. Jenom doufám, že nikdo z vás neprogramuje a jen si honíte ego v diskuzi.

Ja bych zase byl radeji, kdyby cast lidi, kteri do teto diskuse prispeli, byla vzorem pro ostatni "programatory". Lepicu bez mozku je na trhu vice nez dost.

V reálném programu je jedno, jestli je obdélník čtverec. Hlavně že funguje efektivně, je to stručné a čitelné. BTW, když se tady někdo zeptá na řešení konkrétní úlohy, tak mu místní architekti nejsou schopni poradit. např. https://forum.root.cz/index.php?topic=13363.0
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 12:41:13
ja som to implementoval v style:

Kód: [Vybrat]
public class Base {
 
   public void ConnectionChanged() {}

}

public class Class1 : Base
{
    private Obj1 _field;

    public Class1(){
      _field = Factory.Get(IObj1);
      _field.ConnectionChanged += OnConnectionChanged;
    }

     private void OnConnectionChanged() {  base.ConnectionChanged; }
}

tak este raz :)

Ja odpoviem, ze zavisi od situacie.  Ak je to teda C# a nepokazi vam to hierarchiu dedenia, spravit nadtriedu so spolocnym spravanim je uplne legitimny pristup. Dalej je mozne pouzit navrhovy vzor adapter, v ktorom je vyuzita delegacia na povodnu triedu + pridane nejake metody. (Vo vzorovych prikladoch sa neda povodny objekt menit, ale spravil by som "mutanta" medzi adapterom a strategy. V strategy sa da delegat menit). C# neovladam, takze vam to tu nenakodim, ale hadam pri troche googlenia sa da pochopit, na co myslim :)
Název: Re:Dědičnost dnes
Přispěvatel: Questor 19. 01. 2017, 13:00:24
Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

Řeč byla o tom, co to je "původní OOP". Pojem OOP použil poprvé Alan Kay, a to v souvislosti se Smalltalkem. Byl jsi to ty, kdo tu začal slovíčkařit o tom, co to je "původní OOP". Řekl bych, že my ostatní tak nějak chápeme, že OOP zahrnuje více konceptů (sám jsem to tu už zmínil). A proto odkazuje-li někdo na ten smalltalkovský, tak obrat "původní OOP" je tedy zcela na místě a srozumitelný. I z toho důvodu, že narozdíl od Simuly se Smalltalk jako první objektový jazyk začal používat i v praxi a používá se dodnes.
Že se Smalltalk inspiroval (mimo jiné) i Simulou tu nikdo nezpochybňuje. Ale protestanti tu jsou taky až od Luthera, přestože se inspirovali (mimo jiné) i husity. Ačkoli jsou husité dnes často řazeni mezi protestantská hnutí, tak hovořit o nich jako o "původních protestantech" by bylo přinejmenším zavádějící.

Lenze povodne OOP sa nepresadilo... zato to moderne, ktore nevychadza zo smalltalku, ale zo Simuly 67 ano. Smalltalkovske OOP je dnes mrtve. Posledny kliniec do rakvy bol jazyk swift ktory pochoval Objective C.

Slova postupom casu zvyknu menit zmysel. Ved napriklad kedysi sa slovom mini-pocitac oznacovali pocitace ktore sa zmestili sa do jednej miestnosti, dnes za mini pocitace povazujeme vselico od single board PC cez laptopy az po nettopy ale rozhodne nie toto https://en.wikipedia.org/wiki/Minicomputer#/media/File:Pdp-11-40.jpg

Aj pod pojmom OOP dnes ludia chapu skor objektovy model z C++, Javy a C# a malokto z beznych programatorov vobec vie o nejakom Smalltalku alebo posielani sprav.
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 13:10:40
Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

Řeč byla o tom, co to je "původní OOP". Pojem OOP použil poprvé Alan Kay, a to v souvislosti se Smalltalkem. Byl jsi to ty, kdo tu začal slovíčkařit o tom, co to je "původní OOP". Řekl bych, že my ostatní tak nějak chápeme, že OOP zahrnuje více konceptů (sám jsem to tu už zmínil). A proto odkazuje-li někdo na ten smalltalkovský, tak obrat "původní OOP" je tedy zcela na místě a srozumitelný. I z toho důvodu, že narozdíl od Simuly se Smalltalk jako první objektový jazyk začal používat i v praxi a používá se dodnes.
Že se Smalltalk inspiroval (mimo jiné) i Simulou tu nikdo nezpochybňuje. Ale protestanti tu jsou taky až od Luthera, přestože se inspirovali (mimo jiné) i husity. Ačkoli jsou husité dnes často řazeni mezi protestantská hnutí, tak hovořit o nich jako o "původních protestantech" by bylo přinejmenším zavádějící.

Lenze povodne OOP sa nepresadilo... zato to moderne, ktore nevychadza zo smalltalku, ale zo Simuly 67 ano. Smalltalkovske OOP je dnes mrtve. Posledny kliniec do rakvy bol jazyk swift ktory pochoval Objective C.

Slova postupom casu zvyknu menit zmysel. Ved napriklad kedysi sa slovom mini-pocitac oznacovali pocitace ktore sa zmestili sa do jednej miestnosti, dnes za mini pocitace povazujeme vselico od single board PC cez laptopy az po nettopy ale rozhodne nie toto https://en.wikipedia.org/wiki/Minicomputer#/media/File:Pdp-11-40.jpg

Aj pod pojmom OOP dnes ludia chapu skor objektovy model z C++, Javy a C# a malokto z beznych programatorov vobec vie o nejakom Smalltalku alebo posielani sprav.

V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?
Název: Re:Dědičnost dnes
Přispěvatel: Inkvizitor 19. 01. 2017, 14:14:41
Nad "programátorskými" diskuzemi na rootu nezbývá než kroutit hlavou. Z toho by se skoro dal založit nový lamer. Jenom doufám, že nikdo z vás neprogramuje a jen si honíte ego v diskuzi.

Ja bych zase byl radeji, kdyby cast lidi, kteri do teto diskuse prispeli, byla vzorem pro ostatni "programatory". Lepicu bez mozku je na trhu vice nez dost.

V reálném programu je jedno, jestli je obdélník čtverec. Hlavně že funguje efektivně, je to stručné a čitelné. BTW, když se tady někdo zeptá na řešení konkrétní úlohy, tak mu místní architekti nejsou schopni poradit. např. https://forum.root.cz/index.php?topic=13363.0

Program ma dve strany. Jedna je, jak realne funguje a druha je, jak se k te implementaci doslo a jestli se v ni nekdo i v budoucnu vyzna.

Je jasne, ze otazka, zda je ctverec specialnim pripadem obdelnika nebo ne (a zda tedy ma byt jeho podtridou v OOP) je dost umela. Ale za kazdym slusne napsanym programem by mel byt nejaky rozumny myslenkovy model a idealne by v nem mel byt rozpoznatelny. A jsem presvedcen, ze nekteri lide pisi programy ad hoc a mozna tem lepsim z nich i dost dobre funguji. Pak jsou jini vyvojari, kteri vzdycky za kodem vidi nejakou (z hlediska lidskeho uvazovani) konzistentni strukturu, ktera je dulezitou soucasti navrhu a implementace.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 19. 01. 2017, 15:20:02
Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

Řeč byla o tom, co to je "původní OOP". Pojem OOP použil poprvé Alan Kay, a to v souvislosti se Smalltalkem. Byl jsi to ty, kdo tu začal slovíčkařit o tom, co to je "původní OOP". Řekl bych, že my ostatní tak nějak chápeme, že OOP zahrnuje více konceptů (sám jsem to tu už zmínil). A proto odkazuje-li někdo na ten smalltalkovský, tak obrat "původní OOP" je tedy zcela na místě a srozumitelný. I z toho důvodu, že narozdíl od Simuly se Smalltalk jako první objektový jazyk začal používat i v praxi a používá se dodnes.
Že se Smalltalk inspiroval (mimo jiné) i Simulou tu nikdo nezpochybňuje. Ale protestanti tu jsou taky až od Luthera, přestože se inspirovali (mimo jiné) i husity. Ačkoli jsou husité dnes často řazeni mezi protestantská hnutí, tak hovořit o nich jako o "původních protestantech" by bylo přinejmenším zavádějící.

Lenze povodne OOP sa nepresadilo... zato to moderne, ktore nevychadza zo smalltalku, ale zo Simuly 67 ano. Smalltalkovske OOP je dnes mrtve. Posledny kliniec do rakvy bol jazyk swift ktory pochoval Objective C.

Slova postupom casu zvyknu menit zmysel. Ved napriklad kedysi sa slovom mini-pocitac oznacovali pocitace ktore sa zmestili sa do jednej miestnosti, dnes za mini pocitace povazujeme vselico od single board PC cez laptopy az po nettopy ale rozhodne nie toto https://en.wikipedia.org/wiki/Minicomputer#/media/File:Pdp-11-40.jpg

Aj pod pojmom OOP dnes ludia chapu skor objektovy model z C++, Javy a C# a malokto z beznych programatorov vobec vie o nejakom Smalltalku alebo posielani sprav.

A co Python? Ruby? To, co je v původním OOP hračka, se v těch jazycích typu C++ musí pracně řešit různými oklikami a serepetičkami skrytými pod pojmem "design patterns".
Původní OOP je založeno na velmi pozdní vazbě a tento koncept rozhodně není mrtvý. Spíše si lidé dnes více a více uvědomují, že bez toho se rozumně objektově programovat nedá.

Co se týče minipočítačů, tak je mi vcelku jedno, co si pod tím představují laici a amatéři. Profík ví, že se tím označují počítače typu PDPček apod. z přelomu 60. a 70. let.
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 15:55:47
Uz to tu nepozeram, zasa sa tu slovickari meraju sa penisy.
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 16:59:53
Uz to tu nepozeram, zasa sa tu slovickari meraju sa penisy.

penis si tu poměřujete vy

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak :)

Můžete napsat podle mého názoru je to špatně, nebo podle této knihy a tohoto autora je to špatně, ale nemůžete napsat, že je to špatně a urážet lidi s jiným názorem. V tomto oboru neexistuje absolutní pravda.
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 17:24:02
Uz to tu nepozeram, zasa sa tu slovickari meraju sa penisy.

penis si tu poměřujete vy

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak :)

Můžete napsat podle mého názoru je to špatně, nebo podle této knihy a tohoto autora je to špatně, ale nemůžete napsat, že je to špatně a urážet lidi s jiným názorem. V tomto oboru neexistuje absolutní pravda.

Ale existuju best practices, prosim netykajte mi.
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 17:33:33
Ale existuju best practices, prosim netykajte mi.

Best practices nejsou jen jedny. Každých pár let je za best practices považováno něco jiného. Kde vám tykám?
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 17:48:35
Ale existuju best practices, prosim netykajte mi.

Best practices nejsou jen jedny. Každých pár let je za best practices považováno něco jiného. Kde vám tykám?

Prepacte, netykate mi, zle som pozeral. Ale Pouzitie dedenia miesto delegacie pri duplicite kodu nebola best practice snad nikdy. Da sa to tak robit, iba ak podobne dedenie dava zmysel. Tu je relevantna litertura https://www.google.sk/search?q=compsition+over+inheritance .  https://en.wikipedia.org/wiki/Delegation_pattern.   

Typicky z vlasy pritiahnuty priklad je, ked osoba ma Usta s metodou papaj().  Potom ale clovek poterebuje tiez jest a tak  moze nastat  Clovek extends Usta.  Podobne je to pritiahnute s vynimanim duplikovaneho kodu do parenta. Ano, da sa to, len to sposobuje problemy.
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 18:39:45
Ale existuju best practices, prosim netykajte mi.

Best practices nejsou jen jedny. Každých pár let je za best practices považováno něco jiného. Kde vám tykám?

Prepacte, netykate mi, zle som pozeral. Ale Pouzitie dedenia miesto delegacie pri duplicite kodu nebola best practice snad nikdy. Da sa to tak robit, iba ak podobne dedenie dava zmysel. Tu je relevantna litertura https://www.google.sk/search?q=compsition+over+inheritance .  https://en.wikipedia.org/wiki/Delegation_pattern.   

Typicky z vlasy pritiahnuty priklad je, ked osoba ma Usta s metodou papaj().  Potom ale clovek poterebuje tiez jest a tak  moze nastat  Clovek extends Usta.  Podobne je to pritiahnute s vynimanim duplikovaneho kodu do parenta. Ano, da sa to, len to sposobuje problemy.

To je jeden příklad špatného použití, ale i správná použití dědičnosti slouží k odstranění duplicity.

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Code_reuse

Je otázka, jak moc je ten váš příklad špatný. Uživatele té třídy by nemělo zajímat, jak k té metodě přišla. Dejme tomu, že je to v některých jazycích špatné použití, ale například v pythonu se dědičnost používá k implementaci mixinů podobným způsobem jako ve vašem příkladu.
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 19:00:37
Ale existuju best practices, prosim netykajte mi.

Best practices nejsou jen jedny. Každých pár let je za best practices považováno něco jiného. Kde vám tykám?

Prepacte, netykate mi, zle som pozeral. Ale Pouzitie dedenia miesto delegacie pri duplicite kodu nebola best practice snad nikdy. Da sa to tak robit, iba ak podobne dedenie dava zmysel. Tu je relevantna litertura https://www.google.sk/search?q=compsition+over+inheritance .  https://en.wikipedia.org/wiki/Delegation_pattern.   

Typicky z vlasy pritiahnuty priklad je, ked osoba ma Usta s metodou papaj().  Potom ale clovek poterebuje tiez jest a tak  moze nastat  Clovek extends Usta.  Podobne je to pritiahnute s vynimanim duplikovaneho kodu do parenta. Ano, da sa to, len to sposobuje problemy.

To je jeden příklad špatného použití, ale i správná použití dědičnosti slouží k odstranění duplicity.

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Code_reuse

Je otázka, jak moc je ten váš příklad špatný. Uživatele té třídy by nemělo zajímat, jak k té metodě přišla. Dejme tomu, že je to v některých jazycích špatné použití, ale například v pythonu se dědičnost používá k implementaci mixinů podobným způsobem jako ve vašem příkladu.

Co som pozeral zbezne na pythonove mixiny, tak nezatazuje sa hierarchia dedicnosti, ale sa mixin vytvori zlepenim dvoch tried. Predstavit si BezustyClovek  a Usta a potom ich zlepit, to je tiez trosku sialene, ale aspon to neimplikuje, ze clovek je specializaciou Ust. Skor by som to nazval asi potom Clovek a KonzumacnyAspekt. :)

Literatura: https://pypi.python.org/pypi/mixin/1.1
Název: Re:Dědičnost dnes
Přispěvatel: gll 19. 01. 2017, 19:10:27
Co som pozeral zbezne na pythonove mixiny, tak nezatazuje sa hierarchia dedicnosti, ale sa mixin vytvori zlepenim dvoch tried. Predstavit si BezustyClovek  a Usta a potom ich zlepit, to je tiez trosku sialene, ale aspon to neimplikuje, ze clovek je specializaciou Ust. Skor by som to nazval asi potom Clovek a KonzumacnyAspekt. :)

Literatura: https://pypi.python.org/pypi/mixin/1.1

Tohle je knihovna, která implementuje mixiny pomocí dekoráturu třídy. V podstatě jen přiřadí atributy mixinu dekorované třídě. Běžně se k implementaci mixinů používá i dědičnost.

http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful
Název: Re:Dědičnost dnes
Přispěvatel: balki 19. 01. 2017, 20:54:47
Co som pozeral zbezne na pythonove mixiny, tak nezatazuje sa hierarchia dedicnosti, ale sa mixin vytvori zlepenim dvoch tried. Predstavit si BezustyClovek  a Usta a potom ich zlepit, to je tiez trosku sialene, ale aspon to neimplikuje, ze clovek je specializaciou Ust. Skor by som to nazval asi potom Clovek a KonzumacnyAspekt. :)

Literatura: https://pypi.python.org/pypi/mixin/1.1

Tohle je knihovna, která implementuje mixiny pomocí dekoráturu třídy. V podstatě jen přiřadí atributy mixinu dekorované třídě. Běžně se k implementaci mixinů používá i dědičnost.

http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful

Je to divne. Aj ked vlastne uvazujem, ze v jazyku, kde sa pouziva duck typing to ani tak vadit nemusi.  Ta libka, co som ju nasiel a myslel som si, ze je default sa mi pozdava viac.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 08:28:16
...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ě...

Na redundanci sere pes, ta se objevuje i jinde, to podstatné je, aby třída čtverce zajistila shodnou délku stran, což je triviální. 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.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 08:30:59
Někdo totiž může říct, že obdelník může být speciální případ cltverce...

Obdélník nesplňuje shodnou délku stran čtverce, proto nejde o specializaci. Při specializaci obdélník -> čtverec jsou všechna pravidla zachována a jedno přibývá. Co je na tom nejasného?
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 08:37:40
no, on je čtverec i speciálním případem pravidelného mnohoúhelníku (s n=4), což už je ale úplně jiný strom dědičnosti, ve kterém žádný jiný čtyřúhelník není

Správně. Ale to neznamená, že musím (třeba násobným) děděním postihnout tyto vlastnosti. Dědění slouží pro konstrukci funkční třídy, ne pro splnění všech těchto závislostí. Proto platí, že vytvořit čtverec lze několika způsoby včetně zcela nového zápisu. Vývojář musí vědět, co se mu vyplatí. A v nejhorším vždy platí, že to můžu vyrobit od základu. Užití dědění není povinné!
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 08:44:05
Myslim, ze tohle pro traity napr. ve Scale neplati. Trait si muze urcit do ceho bude namixovan (v podstate interface "this") a muze obsahovat jak stav, tak zpracovani. Casto tak rozdeluji velke tridy do nekolika traitu (a souboru) kvuli prehlednosti...

Pak se skládání traits podobá násobné dědičnosti. Já to slyšel a je jako mixins. Ale je to šumák, víme, o co jde.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 08:50:40
Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.
Doktorát z čeho? Historie "starých Slováků"? Podle toho, jak tu trolíš, nemáš ani základku a někde v Horních Uhrách se opíráš o lopatu a v jednom kuse nasáváš borovičku. Tak nás všechny ušetř těch kravin a dej si odchod.

Bez urážek!
Pan Balki si může veškeré uvedené termíny dohledat.
Název: Re:Dědičnost dnes
Přispěvatel: karel 20. 01. 2017, 09:48:40
Ale existuju best practices, prosim netykajte mi.

Best practices nejsou jen jedny. Každých pár let je za best practices považováno něco jiného. Kde vám tykám?

Prepacte, netykate mi, zle som pozeral. Ale Pouzitie dedenia miesto delegacie pri duplicite kodu nebola best practice snad nikdy. Da sa to tak robit, iba ak podobne dedenie dava zmysel. Tu je relevantna litertura https://www.google.sk/search?q=compsition+over+inheritance .  https://en.wikipedia.org/wiki/Delegation_pattern.   

Typicky z vlasy pritiahnuty priklad je, ked osoba ma Usta s metodou papaj().  Potom ale clovek poterebuje tiez jest a tak  moze nastat  Clovek extends Usta.  Podobne je to pritiahnute s vynimanim duplikovaneho kodu do parenta. Ano, da sa to, len to sposobuje problemy.

To je jeden příklad špatného použití, ale i správná použití dědičnosti slouží k odstranění duplicity.

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Code_reuse

Je otázka, jak moc je ten váš příklad špatný. Uživatele té třídy by nemělo zajímat, jak k té metodě přišla. Dejme tomu, že je to v některých jazycích špatné použití, ale například v pythonu se dědičnost používá k implementaci mixinů podobným způsobem jako ve vašem příkladu.
Čet sis tu stránku na wikipedii (teď navíc nehodnotím jak je wikipedia autoritativní zdroj, zvlášť odstavec plný odkazů "citation needed")? Mixin je v zásadě trochu jiný princip než dědění i když se často pomocí dědění implementuje. Dálší je private dědičnost v C++, která je ale z principu rozbitá a rozhodně nedoporučuju to používat (přetypuješ na předka a můžeš volat privatní zděděné metody). A v celém tom odstavci popisujou antipattern fragile base class, ke kterému právě code reuse pomocí dědičnosti často vede. Zkus teda ukázat nějaký příklad použití, který je dobře. Celá tahle diskuze je o tom, že vždycky se řekne, to bylo špatně použité, ale ještě jsem neviděl příklad toho dobrého použití.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 09:53:01
...Na tomto problému je dobré jen to, že je vidět, že v různých situacích se hodí různá řešení a recept na to jediné správné prostě bez znalosti dalšího kontextu není.

Zde se hodí odkaz, kde to autor shrnul za nás: http://prog-story.technicalmuseum.cz/images/dokumenty/Programovani-TSW-1975-2014/2001/2001-15.pdf (http://prog-story.technicalmuseum.cz/images/dokumenty/Programovani-TSW-1975-2014/2001/2001-15.pdf)
Autor danou problematiku rozebírá a uvádí, že v různých fázích analýzy a implementace se může hierarchie tříd jevit jinak.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 09:59:50
Co to je "původní OOP"? Něco ještě před Simulou? Protože pojetí tříd, objektů, dědičnosti a virtuálních funkcí v jazyce Simula 67 je blíž dnešním jazykům jako C++ nebo Java, než Smalltalku, který vznikl až po Simule.

Pro mě je nejohebnější koncept OOP ten od Kaye ze Smalltalku. Třeba je něco lepšího, ale nevím o tom.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 10:07:54
To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

Ano, Kay určitě vycházel ze Simuly. Slovo "omezeně" je myslím v souvislosti se Smalltalkem vyloženě nevhodné, kdy Smalltalk si např. nevyrobil omezení v podobě podtypového polymorfismu a silný zůstává v pozdní vazbě a metatřídní implementaci tříd. To má dnes jen pár(?) jazyků.
Název: Re:Dědičnost dnes
Přispěvatel: karel 20. 01. 2017, 10:08:45
Ještě teda z článku na wikipedii mě zaujala část: https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Issues_and_alternatives

Konrétně věta: "Reportedly, Java inventor James Gosling has spoken against implementation inheritance, stating that he would not include it if he were to redesign Java."

Takže evidentně si za děděním chování nestojí ani autoři jazyka, který je tímhle způsobem programování asi nejznámější.
Název: Re:Dědičnost dnes
Přispěvatel: ava 20. 01. 2017, 10:19:34
Někdo totiž může říct, že obdelník může být speciální případ cltverce...

Obdélník nesplňuje shodnou délku stran čtverce, proto nejde o specializaci. Při specializaci obdélník -> čtverec jsou všechna pravidla zachována a jedno přibývá. Co je na tom nejasného?

Jak psal Satai Nekola, ctverec dedici z obdelnika je v pohode pouze, pokud je immutable, jinak porusuje Liskov Substitution Principle, tedy instance podtypu ma stejne ocekavane vlastnosti jako instance nadtypu.

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

b = obdelnik.obsah()/obdelnik.a()
obdelnik.setSideA(10)
obdelnik.obsah() == b * obdelnik.a()

coz muze prekvapit a potrapit.

No a kdyz z nej podedim ctverec, tam je zase ocekavana vlastnost, ze delka A == delka B.

A ted co se ma stat, kdyz zavolam setSideA na ctverci jakozto potomku obdelnika? At vymyslis jakekoliv reseni, vzdy to bude z nektere strany davat neocekavane chovani.

Pokud jsou obdelnik a ctverec immutable, timto neduhem netrpi (netvrdim nic o tom, co se ocekava, ze se stane, kdyz zavolam setSideA, protoze zadna takova mutator metoda neexistuje).

Tohle si myslim je dost zakladni princip, ktery by kazdy programator v jazycich s subtype polymorfismem mel znat.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 20. 01. 2017, 10:52:39
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 20. 01. 2017, 11:01:54
Jinak by treba neplatila posloupnost

b = obdelnik.obsah()/obdelnik.a()
obdelnik.setSideA(10)
obdelnik.obsah() == b * obdelnik.a()

coz muze prekvapit a potrapit.

Aj! Však je to taky ze své podstaty totálně špatně! "B", "A" i obsah jsou vlastnosti objektu, které máte získávat od něj. A ne si je počítat bokem vedle. Vždyť jste tu předvedl naprosto flagrantní porušení zapouzdření!

Nicméně zařazuji do své sbírky odstrašujících příkladů.  :)
Název: Re:Dědičnost dnes
Přispěvatel: karel 20. 01. 2017, 11:02:19
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.
Já teda očekávám, že program dělá jen věci které jsou v něm jasně napsané a ne věci o kterých se nikde nezmiňuje. Tak jsem asi špatný programátor a dávám do svých programů málo matematických chytáků.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 20. 01. 2017, 11:07:02
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Ale no tak. Kód se píše pro lidi a pokud setA má neočekávané vedlejší efekty na b a odpálí navíc jaderné hlavice, je to očividně špatný návrh.

Že takové omezení neplyne z nějaké matematické představy, co máš, je jedno.

Naopak pokud se člověk chce matematikou inspirovat, tak se celé téhle opičárně raději vyhne úplně.
Název: Re:Dědičnost dnes
Přispěvatel: Inkvizitor 20. 01. 2017, 11:07:51
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Prosil bych nejaky odkaz. Jestlize zmena strany u obdelnika *obecne* znamena, ze se druhy rozmer necha jak byl (a to je zcela rozumne ocekavani), proc by to u ctverce (ktery je take obdelnikem, kdyz jsme to takhle "chytre" nadefinovali) melo byt jinak.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 20. 01. 2017, 11:14:24
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Prosil bych nejaky odkaz. Jestlize zmena strany u obdelnika *obecne* znamena, ze se druhy rozmer necha jak byl (a to je zcela rozumne ocekavani), proc by to u ctverce (ktery je take obdelnikem, kdyz jsme to takhle "chytre" nadefinovali) melo byt jinak.

To neřeš. Tohle je očividně porušení kontraktu. Ať už někde popsaného ve specce, definovaného testy nebo očekávaného.
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 11:14:52
Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.
Doktorát z čeho? Historie "starých Slováků"? Podle toho, jak tu trolíš, nemáš ani základku a někde v Horních Uhrách se opíráš o lopatu a v jednom kuse nasáváš borovičku. Tak nás všechny ušetř těch kravin a dej si odchod.

Bez urážek!
Pan Balki si může veškeré uvedené termíny dohledat.

Mam sa ohlasit na sekretariate ceskej drevarskej univerzity v humpolci?
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 20. 01. 2017, 11:21:40
Jinak by treba neplatila posloupnost

b = obdelnik.obsah()/obdelnik.a()
obdelnik.setSideA(10)
obdelnik.obsah() == b * obdelnik.a()

coz muze prekvapit a potrapit.

Aj! Však je to taky ze své podstaty totálně špatně! "B", "A" i obsah jsou vlastnosti objektu, které máte získávat od něj. A ne si je počítat bokem vedle. Vždyť jste tu předvedl naprosto flagrantní porušení zapouzdření!

Nicméně zařazuji do své sbírky odstrašujících příkladů.  :)

Nějaký podobný kód může být snadno součástí property based testů pro obdélník.
Ty by pochopitelně měly pricházet i pro podtřídy.

Název: Re:Dědičnost dnes
Přispěvatel: stryko sam 20. 01. 2017, 11:22:48
Cele je to zase len umely problem.

Kód: [Vybrat]
class Shape extends React.Component
{
  get style()
  {
    return { backgroundColor: this.props.fillColor };
  }

  render()
  {
    return (
      <div className="Shape" style={this.style} />
    )
  }
}

class Square extends Shape
{
  get style()
  {
    return {
    ...super.style,
        width: this.props.a,
        height: this.props.a
    };
  }
}

class Rectangle extends Shape
{
  get style()
  {
    return {
    ...super.style,
        width: this.props.a,
        height: this.props.b
    };
  }
}

ReactDOM.render(<div>
  <Rectangle a={150} b={180} fillColor="red" />
  <Square a={150} fillColor="green" />
</div>, document.getElementById("Container"));
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 12:07:40
Čet sis tu stránku na wikipedii (teď navíc nehodnotím jak je wikipedia autoritativní zdroj, zvlášť odstavec plný odkazů "citation needed")? Mixin je v zásadě trochu jiný princip než dědění i když se často pomocí dědění implementuje. Dálší je private dědičnost v C++, která je ale z principu rozbitá a rozhodně nedoporučuju to používat (přetypuješ na předka a můžeš volat privatní zděděné metody). A v celém tom odstavci popisujou antipattern fragile base class, ke kterému právě code reuse pomocí dědičnosti často vede. Zkus teda ukázat nějaký příklad použití, který je dobře. Celá tahle diskuze je o tom, že vždycky se řekne, to bylo špatně použité, ale ještě jsem neviděl příklad toho dobrého použití.

Kdo ohodnotí, jestli je to dobře? Nepsal jsem o c++, ale o pythonu. Tam se to používá. Privátní metody tam neexistují.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 20. 01. 2017, 12:17:40
Já teda očekávám, že program dělá jen věci které jsou v něm jasně napsané a ne věci o kterých se nikde nezmiňuje. Tak jsem asi špatný programátor a dávám do svých programů málo matematických chytáků.

1. To je přece naprosté nepochopení principu zapouzdření a blackboxu.
2. Právě proto dříve k programování takové jedince, kterým dělá potíže rozdíl mezi implikací a ekvivalencí a výrok "pro všechna X platí" znegují jako "pro žádné X neplatí", raději vůbec nepouštěli. A dělali dobře, jak je vidět.
Při vší úctě, jestli toto někdo považuje za matematický chyták, tak má raději někde tahat kabely po barácích, ale rozhodně by ho neměli pouštět k profesionálnímu programování! Tam akorát nadělá víc škody než užitku.

Ale no tak. Kód se píše pro lidi a pokud setA má neočekávané vedlejší efekty na b a odpálí navíc jaderné hlavice, je to očividně špatný návrh.

Jenže tady se nebavíme o tom, že by objekt obdélník, resp. čtverec odpaloval jaderné hlavice, ale o tom, že nějak reaguje na žádost o modifikaci nějaké své vlastnosti. Zasláním zprávy objektu tento objekt o něco požádáme. Jak se s tím vypořádá je interní věcí toho objektu. Že taková žádost může mít dopad i na jiné vlastnosti toho objektu by mělo být každému jasné. Jediné, co zde mohu očekávat, je to, že po poslání zprávy, jež má za cíl měnit vlastnosti toho objektu, nemohu spoléhat na jeho stav před zasláním této zprávy. Zajímají-li vás rozměry objektu obdélník, zeptejte se na ně toho obdélníku, protože ten jediný je relevantním zdrojem takové informace. Nikdo o nich totiž neví víc, než on sám.

Tady, jak tak koukám, narážíme na nepochopení samotné podstaty a základů objektového návrhu.

Prosil bych nejaky odkaz. Jestlize zmena strany u obdelnika *obecne* znamena, ze se druhy rozmer necha jak byl (a to je zcela rozumne ocekavani), proc by to u ctverce (ktery je take obdelnikem, kdyz jsme to takhle "chytre" nadefinovali) melo byt jinak.

Jaký odkaz, pro boha? Odkaz na co? Někteří lidé už jsou tak zblblí, že potřebují i odkaz na tvrzení, že jedna a jedna jsou dvě, nebo že s největší pravděpodobností slunce vyjde i zítra.
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

Pokud bude specifikováno, že posláním zprávy setSideA objektu obdélník se změní strana A a zároveň se zaručuje, že nedojde ke změně strany B, tak souhlasím s vámi se všemi. Ale pokud budu chtít odvozovat čtverec od obdélníka, tak nic takového do specifikace psát nebudu a pokud si to někdo domyslí sám ze své iniciativy, tak je s prominutím iniciativní hádejte co...

To neřeš. Tohle je očividně porušení kontraktu. Ať už někde popsaného ve specce, definovaného testy nebo očekávaného.

Ne! Tohle je velmi rozšířený nešvar, který se vždycky u studentů systematicky mýtil už od prvních semestrů technických a jiných exaktních vysokých škol, totiž naučit je, aby si nedomýšleli navíc nic, co není explicitně řečeno.  Když řeknu, že něco platí o nějaké reálné funkci jedné reálné proměnné, aniž bych někde explicitně řekl, že mám na mysli jen funkce spojité, tak v žádném případě nemohu očekávat, že se to jaksi tak nějak mimochodem určitě myslí. Kolik studentů na těchto "detailech" vyhořelo tak, že nakonec ty školy vůbec neudělali a díky tomu se naštěstí k žádnému programování prakticky nedostali...

Samozřejmě už vidím, jak mě nějaký místní "chytrák" chytá za slovo s tím, že ten obdélník by tak mohl teoreticky být i nějaký hyperkvádr, protože nikde není řečeno, že ty rozměry nemohou být komplexní, apod. Ale to je právě ten chybějící cit pro věc.
V každém případě, největší pohromou je, když si někdo domýšlí nad rámec toho, co bylo jasně specifikováno. Takže pan Ondra tu už fabuluje o porušení kontraktu (o němž neví zhola nic), specifikací (které si domyslel tak, aby měl pravdu) a chování testů (o nichž na základě zde padnuvších informací nemůže prohlásit nic). Opět nádherná ukázka naprosto chybného a nebezpečného stylu myšlení u programátora.
Název: Re:Dědičnost dnes
Přispěvatel: Inkvizitor 20. 01. 2017, 12:44:18
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

Hm, aha, no jo. Tak se mejte hezky, soudruhu majore.
Název: Re:Dědičnost dnes
Přispěvatel: n 20. 01. 2017, 12:53:25
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Ne. Naopak u obecneho obdelniku PLATI, ze kolme strany k sobe jsou na sobe NEzavisle. Pokud tedy muzete delku stran menit(coz samozrejme nemusi jit) je dost pravdepodobne, ze zmena strany A neovlivni zmenu strany B. Pokud toto neplati, tak to je nejake specialni chovani. A nemodelujete obdelnik ale obdelnik se zavislyma stranama. Coz je nejaka konkretni specializace obdelniku, ktera se chove jinak, nez by je pro obdelnik mozne.
Vy si nejak definujete obdelnik matematicky, ale to je nedostatecna definice, protoze nemate definovano chovani(pokud neni immutable), jenom vysledny stav. V podstate definujete immutable objekt. Je to matematicke zjednoduseni. V realnem svete neexistuji v case nemenne objekty.
Vzhledem k vasem hloupemu vyjadreni o nematematicich bych mohl bych rict, ze to je prave problem matematiku, kteri stavi modely, ktere nepostihuji realitu, ale zjednoduseny model reality a proto matematik programator v realnych systemech nadela vic paseky nez uzitku. :-) Ale samozrejme je to nesmysl. Jen je treba si uvedomit, ze vase matematicka definice obdelniku neni definice obdelniku, ktery se v case muze menit.
Název: Re:Dědičnost dnes
Přispěvatel: n 20. 01. 2017, 12:56:58
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

A zadruhe. Pokud ma setSideA() neocekavane vedlejsi efekty, tak to je chyba, ktera uz nema ani nic spolecneho s OOP, to je priklad poruseni zakladnich programovacich praktik(to bych se i zdrahal nazvat best practices), protoze za to by vam dali za usi uz v predemetu programovani na zakladce.
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 13:02:32
Čet sis tu stránku na wikipedii (teď navíc nehodnotím jak je wikipedia autoritativní zdroj, zvlášť odstavec plný odkazů "citation needed")? Mixin je v zásadě trochu jiný princip než dědění i když se často pomocí dědění implementuje. Dálší je private dědičnost v C++, která je ale z principu rozbitá a rozhodně nedoporučuju to používat (přetypuješ na předka a můžeš volat privatní zděděné metody). A v celém tom odstavci popisujou antipattern fragile base class, ke kterému právě code reuse pomocí dědičnosti často vede. Zkus teda ukázat nějaký příklad použití, který je dobře. Celá tahle diskuze je o tom, že vždycky se řekne, to bylo špatně použité, ale ještě jsem neviděl příklad toho dobrého použití.

Kdo ohodnotí, jestli je to dobře? Nepsal jsem o c++, ale o pythonu. Tam se to používá. Privátní metody tam neexistují.

ještě příklady z použití mixinů v ORM:

https://gist.github.com/YukSeungChan/851967b04d1f7cb6ba56
http://docs.sqlalchemy.org/en/latest/orm/extensions/declarative/mixins.html
https://gist.github.com/techniq/5174410

pomocí mixinů se dají například definovat sloupce opakující se ve více tabulkách.
Název: Re:Dědičnost dnes
Přispěvatel: n 20. 01. 2017, 13:07:17
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

ROFL. "Zmena strany obdelnika... ...se nemusi zmenit vubec." =>Takze to neni zmena. Takze setA udela NIC. => Taky byste mohl predpoklada, ze 3 krat 3 rovna se bagr. Protoze prece nebudete neco predpokladat.

 Doufam, ze se nezivite programovanim. Pokud se zivite jeho ucenim, tak to je hodne spatny (v tom pripade byste mel mozna rict, kde ucite, pokud to tak je, aby se pripadni programatori vyhli vasi skole. Pripadne koho se mam u pohovoru ptat, jestli jste ho nahodou neucil, abychom neztraceli zbytecne cas).
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 20. 01. 2017, 13:07:30
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

A zadruhe. Pokud ma setSideA() neocekavane vedlejsi efekty, tak to je chyba, ktera uz nema ani nic spolecneho s OOP, to je priklad poruseni zakladnich programovacich praktik(to bych se i zdrahal nazvat best practices), protoze za to by vam dali za usi uz v predemetu programovani na zakladce.

Přesně tak.

Kiwi povídá píčoviny. Asi zažil první semestr na škole a je z toho úplně mimo ;D S matikou ty jeho nesmysly nemají nic společného. Na hloupé kamarády to ale v hospodě dojem udělat může 8)
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 13:50:31
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

ROFL. "Zmena strany obdelnika... ...se nemusi zmenit vubec." =>Takze to neni zmena. Takze setA udela NIC. => Taky byste mohl predpoklada, ze 3 krat 3 rovna se bagr. Protoze prece nebudete neco predpokladat.

 Doufam, ze se nezivite programovanim. Pokud se zivite jeho ucenim, tak to je hodne spatny (v tom pripade byste mel mozna rict, kde ucite, pokud to tak je, aby se pripadni programatori vyhli vasi skole. Pripadne koho se mam u pohovoru ptat, jestli jste ho nahodou neucil, abychom neztraceli zbytecne cas).

Kiwi má pravdu. Vy se odvoláváte na nějaké konvence, které nemusí platit všude.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 15:07:41
Třída není realizátorem zapouzdření, tím je viditelnost metod a vlastností. Třída je realizátorem vytváření objektů.

Nejsem si jisty, co tim chces rict. Co ja chci rict je, ze zapouzdreni lze treba v Jave realizovat dvema zpusoby - viditelnosti v ramci tridy a viditelnosti v ramci modulu (package). Ale k cemu je dobre mit dve varianty stejne abstrakce? Nestacil by na to jen modul? Je to proste neortogonalni navrh jazyka.

Že to s třídou nemá co dělat - klidně můžete mít prototypovaný jazyk, který má u metod uvedenu viditelnost.
Jen pro modul je nedostatečná, základní stavební jednotkou jsou objekty. Smalltalk to má jednoduché - vlastnosti protected, metody public, v Squeaku/Pharu i určené metody protected.

Takze v pripade dedeni dat je to opacne, nez pises - tam se prave vyhneme polymorfismu... ...naopak pri dedeni interfacu, coz je zpusob polymorfismu, tenhle problem nevznika.

Nevím, zda má smysl řešit odděleně dědění vlastností a metod, když jsou neoddělitelné.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 15:16:49
Aj pod pojmom OOP dnes ludia chapu skor objektovy model z C++, Javy a C# a malokto z beznych programatorov vobec vie o nejakom Smalltalku alebo posielani sprav.

Jen pro zajímavost: Aby se jazyky jako Smalltalk distancovaly od vámi uvedených hybridních jazyků, které si původní termín OOP přivlastnily, a jejich pojetí OOP, někteří pro ně používají termín čistě objektové jazyky (pure object languages). To myslím vypovídá o mnohém.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 15:21:14
V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?

Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 15:36:25

Jak psal Satai Nekola, ctverec dedici z obdelnika je v pohode pouze, pokud je immutable, jinak porusuje Liskov Substitution Principle, tedy instance podtypu ma stejne ocekavane vlastnosti jako instance nadtypu.

...

Nechápu, co řešíte. Čtverec jako dědic musí zajistit dodržení nového pravidla, že a = b, k tomu stačí překrýt metody, které nastavují strany, aby splnění zajistily. Pak můžete se čtvercem mutovat, jak chcete, pořád to bude čtverec.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 20. 01. 2017, 15:40:49
V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?

Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Tak vidíš a jaký je to bastl. Dělají v tom jen lopaty, které nikdy nepochopí programování. Prostě mi přijde divné, proč používáš OOP pro nějaký paskvil, který je mrtvý a zůstal maximálně u skriptovacích jazyků na minivěci.

Takže znakem "pure" OOP je co? Normální OOP totiž vypadá daleko lépe a pure znamená horší, což obvykle bývá naopak.
Název: Re:Dědičnost dnes
Přispěvatel: SB 20. 01. 2017, 15:46:09
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).
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 15:53:21
V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?

Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Javascript je prototype-based, pre objekty tam neplati dualizmus trieda-instancia, ale objekty sa vytvaraju pomocou klonovania existujucich objektov. To je tak trosku podstatny rozdiel. Ano aj v javascripte su triedy, ale je to len syntakticky cukor.  Skor je javascript podobny self-u . (Self je sice dialekt smalltalku ale s podstatnym rozdielom, ze je prototype-based)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 20. 01. 2017, 16:05:15
To je jak u malých. Zejména Kiwi.

Programuje se pro lidi. Jestli ti to v tom prvním semestru neozřejmili...

Každý objekt má kopec implicitních vlastností. Že ti setA neodpálí rakety je mezi nimi.

Zrovna kontrakt, co ti rozbije tu hierarchii mutable čtverce a obdélníku, bude dost možná i explicitní v nějakém property based testu:
Kód: [Vybrat]
Obdélník o, r > 0
 =>
      obsah1 = o.obsah()
      o.setA(r * o.getA())
      r * obsah1 == o.obsah() až na epsilon
   
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 20. 01. 2017, 16:07:25

Jak psal Satai Nekola, ctverec dedici z obdelnika je v pohode pouze, pokud je immutable, jinak porusuje Liskov Substitution Principle, tedy instance podtypu ma stejne ocekavane vlastnosti jako instance nadtypu.

...

Nechápu, co řešíte. Čtverec jako dědic musí zajistit dodržení nového pravidla, že a = b, k tomu stačí překrýt metody, které nastavují strany, aby splnění zajistily. Pak můžete se čtvercem mutovat, jak chcete, pořád to bude čtverec.

Vážně to nechápeš ;)

Nedá se to rozumně udělat při zachování i kontraktu pro Obdélník. Dále viz LSP
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 16:13:55
V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?

Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Javascript je prototype-based, pre objekty tam neplati dualizmus trieda-instancia, ale objekty sa vytvaraju pomocou klonovania existujucich objektov. To je tak trosku podstatny rozdiel. Ano aj v javascripte su triedy, ale je to len syntakticky cukor.  Skor je javascript podobny self-u . (Self je sice dialekt smalltalku ale s podstatnym rozdielom, ze je prototype-based)

Objekty se vytváří konstruktorem. Nic se při tom neklonuje. Prototyp zůstává jen jeden.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 20. 01. 2017, 16:36:49
Kiwi povídá píčoviny. Asi zažil první semestr na škole a je z toho úplně mimo ;D

To spíš vy mi připadáte jako děcka s mlíkem na bradě, co v životě nemusela přidávat nějakou funkcionalitu do existujícího projektu, protože zatím si jen patlala párřádkové školní projektíky jakožto one-man-show from scratch.

Takže ještě jednou:

1. Netvrdím, že chování, kdy změním A, ale pod rukama se mi změní i B, je optimální. Takto bych to já nejspíš nenavrhnul, kdyby to bylo na mně. Jenže většina mých zkušeností plyne z praktického života, v němž přijdete k existující věci, která je málokdy navržená optimálně.

2. Pokud někdo navrhne třídu "obdélník" jakožto třídu měnitelných objektů, z níž je navíc dovoleno odvozovat podtřídy, tak je třeba se srovnat s tím, že někdo může potřebovat čtverec jako speciální případ obdélníku, a tedy s výše popsaným "záhadným" chováním setSideA, setSideB; nemusí to končit čtvercem; další bude potřebovat zlatý obdélník (tedy se stranami v poměru zlatého řezu) a nakonec přijde někdo, kdo bude chtít modrý obdélník (dopad na chování v případě poslání zprávy setColor takovému objektu tu doufám nemusím rozebírat). Znovu zdůrazňuji, že netvrdím, že takto udělaný program je optimálně navržený. Nejspíš by to byl jen jeden z mnoha návrhů, kdybych opět kroutil hlavou, točil oči v sloup a ptal se sám sebe "pro boha, proč takhle", ovšem bez znalosti konkrétního kontextu těžko soudit. Ale:

3. Pokud někdo další bude takto navržený program dále rozvíjet s předpokladem, že přece setSideA nemůže mít za žádných okolností vliv na druhou stranu, nebo že setColor zaručeně povede ke změně barvy na požadovanou, tak veškerou nešikovnost původního návrhu povýší na kvadrát. Protože tak přidá další nadbytečné vazby na úrovni, na níž je nikdo při návrhu nepředpokládal. A kvůli tomuto jeho redundantnímu předpokladu, kterým se mu možná, někde, něco trochu zjednodušilo, se další věci velmi zkomplikují. Stačí, aby obdélník byla netriviální třída, a z přidání triviálního čtverce se stane noční můra jen kvůli tomu, že zas někdo "myslel" a místo aby se obdélníka explicitně dotázal na jeho vlastnosti, jak se sluší a patří, tak si myslí, že si je spočítá lépe než on sám. Což rozhodně je bezprecedentní porušení principu zapouzdření!
A mimochodem to, že objekt reaguje na zprávu podle svého uvážení, je jedním ze základních pilířů objektově orientovaného programování. Proto se tomu taky neříká procedura. To nebyl jen nějaký terminologický fetiš otců-zakladatelů OOP. Různé objekty mohou na stejnou zprávu reagovat různě. Stejný objekt může na stejnou zprávu za různých okolností reagovat různě. Pošlete třídě GeometrickýÚtvar zprávu new #rectangle withA: 10 withB: 10 a obdržíte objekt třídy čtverec (například z důvodu optimalizace). Pošlete mu zprávu setSideB: 20, které samozřejmě čtverec nebude rozumět, tak ji deleguje o úroveň výš, kde se rozhodne o změně třídy na obdélník. To všechno transparentně. A právě o tomto a jiných podobných obratech je objektové programování, má-li to doopravdy ulehčovat práci. A ne o tom, že nacpu funkce a proměnné do tříd a budu dědit do bezvědomí.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 20. 01. 2017, 16:45:46
One-man show není nic špatného. My s Kitem to máme rádi ;D Alespoň nikdo do toho necpe žádné nesmysly.

OK, to pak asi jo. Já bych to použil a určitě nezkoumal, jestli mi setA maže i půl disku. Ale co má s tím společného matika? Naopak by byla hloupost předpokládat, že to maže i ten disk. Taky to může objednávat na Alze, že jo. Ani jedno to ale určitě nedělá. Takže spíše bude problém u tebe. Možná nějaká paranoia?

Do obdélníků se cpát nebudu, na to tu je dost jiných lidí :D
Název: Re:Dědičnost dnes
Přispěvatel: Logik 20. 01. 2017, 16:53:19
Celý problém, který jsem naschvál jen nakousnul a nedořek, je v tomto:

Dědičnost NENÍ vhodná na modelování každého vztahu A is B. Pouze vztahu A is B a A je záměnné pro B. Což v podstatě znamená and A is B a navíc A umí vše co B. Což u čtverce ve vztahu k obdélníku není pravda - a proto modelace čtverce jako speciálního případu obdélníka je někdy špatně.

A naopak - v určitém kontextu se může hodit to, co jsem provokativně nadhodil: pokud budu řešit např. problém optimalizace vyplnění prostoru pomocí dlaždic, tak se mi může hodit nadefinovat čtvercovou dlaždici, která má (mimo pozice) jeden parametr volnosti, a z ní potomka obdélníkovou dlaždici, která má jeden parametr navíc: poměr stran.

Oba tyto vztahy: Čtverec je podmnožinou obdélníka i obdélník je podmnožinou čtverce splňují pouze jednu z výše uvedených podmínek pro správnou dědičnost: obdélník není čtverec, ale čtverec neumí vše, co obdélník. Proto pro obě tyto dědičnosti najdete protipříklady, kdy jejich užití selže.

A to jsem neještě nemluvil o kosočtvercích a kosodélnících: je čtverec speciální případ kosočtverce (fixuje úhel) nebo kosodélníku atd..., atd....

Osobně v praxi používám to, že pro dědění rozhraní, které jsou více o tom, co předmět umí než co předmět je, volím dědění dle "umí", tedy rozhraní obdélníku bych třeba navrhl jako speciální případ k rozhraní čtverce. Naopak u dědičnosti je dobré zachovávat především vztah "is a", ovšem s tím, že pokud bych porušil (používaný) vztah "umím", tak nedědit.

Celé je to způsobeno tím, že dědičnost i rozhraní je jen velké zjednodušení reality. Které lze použít jen potud, pokud to zjednodušení není na úkor porušení vztahů, které je třeba kódem zachytit. Proto někdy je bez problémů popsat čtverec jako obdélník, někdy ne.


PS: Jinak Kiwi má částečně dobrý postřeh s tím, že výše uvedené problémy se zhoršují mutabilitou objektů. Ovšem i bez mutability to je problém: pokud mám třídy A který může mít stav X, a jejího potomka B, který v stavu X být nemůže, tak prostě to je problém, který mi immutabilita nijak neřeší. Protože správná reakce na žádost vrať mi B ve stavu X není z B nejprve udělat A, správná odpověď je říci: já v tom stavu být nemohu.

Jde to vyřešit tím, pokud součástí "protokolu" třídy A je "nastavení do stavu X se nemusí povést". Pak vlastně není problém. Naopak pokud je součástí byť implicitní definice třídy, že přechod do stavu X lze vždy, tak vlastně z definice vidíme, že B nemůže být potomkem A - tedy že čtverec není obdélník.

Z tohoto pohledu by to vlastně immutabilita řešila, akorát třída A by neměla mít metodu: vrať mi sebe ve stavu X, ale vrať mi objekt A, který vznikne ze mě převedením do stavu X. Tedy obdélník i čtverec by měli metodu: vrať_kopii_obdélníku_se_stranou_B. To ovšem není řešením tohoto problému jako celého, pořád je tu problém v "odstraňování schopností", např: Člověk umí běžet. Chromý člověk je člověk, ale běžet neumí.
Název: Re:Dědičnost dnes
Přispěvatel: ava 20. 01. 2017, 17:06:59
Kiwi povídá píčoviny. Asi zažil první semestr na škole a je z toho úplně mimo ;D

To spíš vy mi připadáte jako děcka s mlíkem na bradě, co v životě nemusela přidávat nějakou funkcionalitu do existujícího projektu, protože zatím si jen patlala párřádkové školní projektíky jakožto one-man-show from scratch.

Takže ještě jednou:

1. Netvrdím, že chování, kdy změním A, ale pod rukama se mi změní i B, je optimální. Takto bych to já nejspíš nenavrhnul, kdyby to bylo na mně. Jenže většina mých zkušeností plyne z praktického života, v němž přijdete k existující věci, která je málokdy navržená optimálně.

2. Pokud někdo navrhne třídu "obdélník" jakožto třídu měnitelných objektů, z níž je navíc dovoleno odvozovat podtřídy, tak je třeba se srovnat s tím, že někdo může potřebovat čtverec jako speciální případ obdélníku, a tedy s výše popsaným "záhadným" chováním setSideA, setSideB; nemusí to končit čtvercem; další bude potřebovat zlatý obdélník (tedy se stranami v poměru zlatého řezu) a nakonec přijde někdo, kdo bude chtít modrý obdélník (dopad na chování v případě poslání zprávy setColor takovému objektu tu doufám nemusím rozebírat). Znovu zdůrazňuji, že netvrdím, že takto udělaný program je optimálně navržený. Nejspíš by to byl jen jeden z mnoha návrhů, kdybych opět kroutil hlavou, točil oči v sloup a ptal se sám sebe "pro boha, proč takhle", ovšem bez znalosti konkrétního kontextu těžko soudit. Ale:

3. Pokud někdo další bude takto navržený program dále rozvíjet s předpokladem, že přece setSideA nemůže mít za žádných okolností vliv na druhou stranu, nebo že setColor zaručeně povede ke změně barvy na požadovanou, tak veškerou nešikovnost původního návrhu povýší na kvadrát. Protože tak přidá další nadbytečné vazby na úrovni, na níž je nikdo při návrhu nepředpokládal. A kvůli tomuto jeho redundantnímu předpokladu, kterým se mu možná, někde, něco trochu zjednodušilo, se další věci velmi zkomplikují. Stačí, aby obdélník byla netriviální třída, a z přidání triviálního čtverce se stane noční můra jen kvůli tomu, že zas někdo "myslel" a místo aby se obdélníka explicitně dotázal na jeho vlastnosti, jak se sluší a patří, tak si myslí, že si je spočítá lépe než on sám. Což rozhodně je bezprecedentní porušení principu zapouzdření!
A mimochodem to, že objekt reaguje na zprávu podle svého uvážení, je jedním ze základních pilířů objektově orientovaného programování. Proto se tomu taky neříká procedura. To nebyl jen nějaký terminologický fetiš otců-zakladatelů OOP. Různé objekty mohou na stejnou zprávu reagovat různě. Stejný objekt může na stejnou zprávu za různých okolností reagovat různě. Pošlete třídě GeometrickýÚtvar zprávu new #rectangle withA: 10 withB: 10 a obdržíte objekt třídy čtverec (například z důvodu optimalizace). Pošlete mu zprávu setSideB: 20, které samozřejmě čtverec nebude rozumět, tak ji deleguje o úroveň výš, kde se rozhodne o změně třídy na obdélník. To všechno transparentně. A právě o tomto a jiných podobných obratech je objektové programování, má-li to doopravdy ulehčovat práci. A ne o tom, že nacpu funkce a proměnné do tříd a budu dědit do bezvědomí.

Heh, taky jsem pár let dělal ve smalltalku, teď se snažím spíš o FP přesně abych nemusel řešit takhle idiotské návrhy programů (i když s tím jsem se nepotkal snad ani v tom smalltalkovém kódu). Správný přístup k idiotskému návrhu, když ho uvidím, obzvlášť ve smalltalku, je "refactor mercilessly", v horším případě si tu funkcionalitu udělat vedle a lépe, ale něco na tom stavět je prostě blbě. V praxi na tomhle obdélníkočtvercomutantovi nebudu volat #area nikdy proto, že je nepoužitelné, protože nemá definovatelnou hodnotu (jaký obsah má čtverec, kterému nastavím strany 2 a 3?), takže tuhle hovadskou areu nemůžu použít ve výpočtu, ukázat uživateli, uložit do databáze, prostě nic. Tedy můžu, ale uživatele tím zblbnu, do databáze perzistuji hovadinu, a ve výpočtu zkur*ím další výpočet. To je ovšem jen do extrému dotažený tvůj přístup "nic nepředpokládat", když o návratových hodnotách nemůžu nic předpokládat, tak je taky nemůžu na nic použít, že....

Případně o chování tohohle kódu mohu mít nějaká očekávání (narozdíl od tebe, ty se bát nemusíš), ale nejspíš budou porušena kvůli LSP, takže pak budu křičet na původního autora. Porozumění LSP je tu právě proto, aby takovéhle bastly pokud možno nevznikaly (a dost staticky typovaných jazyků si vynucuje dodržování LSP alespoň co se týče variance anotacemi ko/kontra/invariance u typových parametrů).
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 17:16:51
V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?

Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Javascript je prototype-based, pre objekty tam neplati dualizmus trieda-instancia, ale objekty sa vytvaraju pomocou klonovania existujucich objektov. To je tak trosku podstatny rozdiel. Ano aj v javascripte su triedy, ale je to len syntakticky cukor.  Skor je javascript podobny self-u . (Self je sice dialekt smalltalku ale s podstatnym rozdielom, ze je prototype-based)

Objekty se vytváří konstruktorem. Nic se při tom neklonuje. Prototyp zůstává jen jeden.

https://en.wikipedia.org/wiki/Prototype-based_programming#Object_construction
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 17:29:20
V čem se zásadně liší smalltalk od dynamických OOP jazyků jako javascript?

Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Javascript je prototype-based, pre objekty tam neplati dualizmus trieda-instancia, ale objekty sa vytvaraju pomocou klonovania existujucich objektov. To je tak trosku podstatny rozdiel. Ano aj v javascripte su triedy, ale je to len syntakticky cukor.  Skor je javascript podobny self-u . (Self je sice dialekt smalltalku ale s podstatnym rozdielom, ze je prototype-based)

Objekty se vytváří konstruktorem. Nic se při tom neklonuje. Prototyp zůstává jen jeden.

https://en.wikipedia.org/wiki/Prototype-based_programming#Object_construction

Nemusíte mě přesvědčovat. Já narozdíl od vás znám javascript velice dobře a prakticky ho používám. V těch příkladech se nic neklonuje. Pouze se nastavuje odkaz na prototyp.
Název: Re:Dědičnost dnes
Přispěvatel: spasitel 20. 01. 2017, 17:32:17

Nemusíte mě přesvědčovat. Já narozdíl od vás znám javascript velice dobře a prakticky ho používám. V těch příkladech se nic neklonuje. Pouze se nastavuje odkaz na prototyp.
tak to vam nezavidim, ze v tom delate. to je tak na kulku
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 17:43:33

Nemusíte mě přesvědčovat. Já narozdíl od vás znám javascript velice dobře a prakticky ho používám. V těch příkladech se nic neklonuje. Pouze se nastavuje odkaz na prototyp.
tak to vam nezavidim, ze v tom delate. to je tak na kulku

na kulku je část JS komunity. Stačí si jich nevšímat a nepoužívat každou blbost, která je zrovna in. Jazyk za to nemůže.
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 17:49:49

https://en.wikipedia.org/wiki/Prototype-based_programming#Object_construction

Nemusíte mě přesvědčovat. Já narozdíl od vás znám javascript velice dobře a prakticky ho používám. V těch příkladech se nic neklonuje. Pouze se nastavuje odkaz na prototyp.

Takze wikipedia klame?
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 17:58:46

https://en.wikipedia.org/wiki/Prototype-based_programming#Object_construction

Nemusíte mě přesvědčovat. Já narozdíl od vás znám javascript velice dobře a prakticky ho používám. V těch příkladech se nic neklonuje. Pouze se nastavuje odkaz na prototyp.

Takze wikipedia klame?

nevím, nečetl jsem tu stránku celou. Vidím tam dva příklady vytváření objektu:

Kód: [Vybrat]
Object.setPrototypeOf(bar, foo);

provede

Kód: [Vybrat]
bar.__proto__ = foo;

a

Kód: [Vybrat]
var bar = Object.create( foo );

provede

Kód: [Vybrat]
var bar = {__proto__:foo};

příklad klonování tam nevidím.
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 18:27:13
příklad klonování tam nevidím.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.three = 3;

bar.one; // 1
bar.two; // 2
bar.three; // 3

Opravte ma ak sa mylim, ale klonovanie je o tom, aby obsahoval vzniknuty objekt vlastnosti prototypu. Ak to maju na wikipedii zle, mate volne ruky si to s autormi clanku na wikipedii vydiskutovat.  Myslim, budu radi, ak nebudu uvadzat nepravdy.
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 18:36:49
příklad klonování tam nevidím.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.three = 3;

bar.one; // 1
bar.two; // 2
bar.three; // 3

Opravte ma ak sa mylim, ale klonovanie je o tom, aby obsahoval vzniknuty objekt vlastnosti prototypu. Ak to maju na wikipedii zle, mate volne ruky si to s autormi clanku na wikipedii vydiskutovat.  Myslim, budu radi, ak nebudu uvadzat nepravdy.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.one; // 1
foo.one = 5;
bar.one; // 5

asi si pod slovem klon každý představujeme něco jiného.
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 18:44:09
příklad klonování tam nevidím.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.three = 3;

bar.one; // 1
bar.two; // 2
bar.three; // 3

Opravte ma ak sa mylim, ale klonovanie je o tom, aby obsahoval vzniknuty objekt vlastnosti prototypu. Ak to maju na wikipedii zle, mate volne ruky si to s autormi clanku na wikipedii vydiskutovat.  Myslim, budu radi, ak nebudu uvadzat nepravdy.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.one; // 1
foo.one = 5;
bar.one; // 5

asi si pod slovem klon každý představujeme něco jiného.

Ok, uznavam, ze sa vam moze definicia klonu z wikipedie nepacit. Prototype-based programming, nie je zas az tak bezna zalezitost. Nie je to velmi popularne medzi pragmatikmi, aby sa to rozsirilo viac a umoznilo sirsiu polemiku.
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 18:50:28
příklad klonování tam nevidím.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.three = 3;

bar.one; // 1
bar.two; // 2
bar.three; // 3

Opravte ma ak sa mylim, ale klonovanie je o tom, aby obsahoval vzniknuty objekt vlastnosti prototypu. Ak to maju na wikipedii zle, mate volne ruky si to s autormi clanku na wikipedii vydiskutovat.  Myslim, budu radi, ak nebudu uvadzat nepravdy.

Kód: [Vybrat]
var foo = {one: 1, two: 2};

var bar = Object.create( foo );

bar.one; // 1
foo.one = 5;
bar.one; // 5

asi si pod slovem klon každý představujeme něco jiného.

Ok, uznavam, ze sa vam moze definicia klonu z wikipedie nepacit. Prototype-based programming, nie je zas az tak bezna zalezitost. Nie je to velmi popularne medzi pragmatikmi, aby sa to rozsirilo viac a umoznilo sirsiu polemiku.

v tom článku na wikipedii se o žádném klonování nepíše. O klonování objektů v javascriptu si přečtěte třeba zde:

http://stackoverflow.com/questions/728360/how-do-i-correctly-clone-a-javascript-object

Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 18:57:56
v tom článku na wikipedii se o žádném klonování nepíše. O klonování objektů v javascriptu si přečtěte třeba zde:

http://stackoverflow.com/questions/728360/how-do-i-correctly-clone-a-javascript-object

Kód: [Vybrat]
Object construction

In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 18:59:04
v tom článku na wikipedii se o žádném klonování nepíše. O klonování objektů v javascriptu si přečtěte třeba zde:

http://stackoverflow.com/questions/728360/how-do-i-correctly-clone-a-javascript-object

Kód: [Vybrat]
Object construction

In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

Sorry este raz dal som code miesto quote.

Object construction

Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 19:12:29
Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

jako zdroj je uveden nějaký pseudovědecký článek o hovně. Nepsal jste ho vy? Jasně, že lze objekty i klonovat. Ale zrovna v JS to není nejběžnější způsob jejich vytváření a s prototypy to nemá nic společného. Object.create(foo) nic neklonuje.


Název: Re:Dědičnost dnes
Přispěvatel: n 20. 01. 2017, 20:21:12
Kiwi povídá píčoviny. Asi zažil první semestr na škole a je z toho úplně mimo ;D

To spíš vy mi připadáte jako děcka s mlíkem na bradě, co v životě nemusela přidávat nějakou funkcionalitu do existujícího projektu, protože zatím si jen patlala párřádkové školní projektíky jakožto one-man-show from scratch.

Takže ještě jednou:

1. Netvrdím, že chování, kdy změním A, ale pod rukama se mi změní i B, je optimální. Takto bych to já nejspíš nenavrhnul, kdyby to bylo na mně. Jenže většina mých zkušeností plyne z praktického života, v němž přijdete k existující věci, která je málokdy navržená optimálně.

2. Pokud někdo navrhne třídu "obdélník" jakožto třídu měnitelných objektů, z níž je navíc dovoleno odvozovat podtřídy, tak je třeba se srovnat s tím, že někdo může potřebovat čtverec jako speciální případ obdélníku, a tedy s výše popsaným "záhadným" chováním setSideA, setSideB; nemusí to končit čtvercem; další bude potřebovat zlatý obdélník (tedy se stranami v poměru zlatého řezu) a nakonec přijde někdo, kdo bude chtít modrý obdélník (dopad na chování v případě poslání zprávy setColor takovému objektu tu doufám nemusím rozebírat). Znovu zdůrazňuji, že netvrdím, že takto udělaný program je optimálně navržený. Nejspíš by to byl jen jeden z mnoha návrhů, kdybych opět kroutil hlavou, točil oči v sloup a ptal se sám sebe "pro boha, proč takhle", ovšem bez znalosti konkrétního kontextu těžko soudit. Ale:

3. Pokud někdo další bude takto navržený program dále rozvíjet s předpokladem, že přece setSideA nemůže mít za žádných okolností vliv na druhou stranu, nebo že setColor zaručeně povede ke změně barvy na požadovanou, tak veškerou nešikovnost původního návrhu povýší na kvadrát. Protože tak přidá další nadbytečné vazby na úrovni, na níž je nikdo při návrhu nepředpokládal. A kvůli tomuto jeho redundantnímu předpokladu, kterým se mu možná, někde, něco trochu zjednodušilo, se další věci velmi zkomplikují. Stačí, aby obdélník byla netriviální třída, a z přidání triviálního čtverce se stane noční můra jen kvůli tomu, že zas někdo "myslel" a místo aby se obdélníka explicitně dotázal na jeho vlastnosti, jak se sluší a patří, tak si myslí, že si je spočítá lépe než on sám. Což rozhodně je bezprecedentní porušení principu zapouzdření!
A mimochodem to, že objekt reaguje na zprávu podle svého uvážení, je jedním ze základních pilířů objektově orientovaného programování. Proto se tomu taky neříká procedura. To nebyl jen nějaký terminologický fetiš otců-zakladatelů OOP. Různé objekty mohou na stejnou zprávu reagovat různě. Stejný objekt může na stejnou zprávu za různých okolností reagovat různě. Pošlete třídě GeometrickýÚtvar zprávu new #rectangle withA: 10 withB: 10 a obdržíte objekt třídy čtverec (například z důvodu optimalizace). Pošlete mu zprávu setSideB: 20, které samozřejmě čtverec nebude rozumět, tak ji deleguje o úroveň výš, kde se rozhodne o změně třídy na obdélník. To všechno transparentně. A právě o tomto a jiných podobných obratech je objektové programování, má-li to doopravdy ulehčovat práci. A ne o tom, že nacpu funkce a proměnné do tříd a budu dědit do bezvědomí.

Naopak, az budete psat velke projekty, na kterych spolupracuji desitky lidi a pres ktere tecou miliardy, tak poznate, ze to co tady navrhujete je uplne k hovnu. Mozna proto se Smalltalk v praxi temer nepouziva(minimalne pokud ho porovnate s "velkymi" jazyky jako c++, java, C# atd...) .
Dle vasich argumentu muze napriklad setA() zrusit samotny objekt. V podstate poslanim jakekoli zpravy (ci volanim metody) zajistite, ze stav objektu kteremu jste zpravu poslal je absolutne nedeterminovatelny z volajici strany.
Dle zakladnich zasad programovani volani nejake metody dela pouze a presne to, co metoda deklaruje ze dela (respektive z vnejsku by se tak mela jevit navenek). A ne, opravdu by nemela mit zadne vedlejsi efekty (zvnejsku pozorovatelne). Pokud vedlejsi efekty ma, tak je struktura spatne navrzena.
K dobrym programovacim konvencim patri to, ze jmeno metody jasne rika, co metoda bude delat. Pokud to neni jasne uz z nazvu, tak vetsinou je to opet spatny navrh. Az budete delat na opravdu velkych projektech na kterych dela spousta lidi, tak poznate ze vase predpoklady vedou k hovnu, ktere se neda ani udrzovat ani rozvijet bez zbytecnych nervu. Za to to nestoji. Mozna je dobre ze existuji lide jako vy, kteri jsou ochotni se vrtat v hnoji, ja, dokud je zajimave prace dost, to delat neminim.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 20. 01. 2017, 20:59:42
Zas diskuze o klonování? To už jsme tady měli ...
JS ma oop systém hodně zprasenej, takže je tam hodně výkladů co je a není klon.
Obecně se ale bere za klon deep copy + shallow copy prototypu.
Jak tady někdo říkal, nejlíp by chtělo udělat deep copy i prototypu, to by zase ale rozbylo instanceof protože to se orientuje podle referencí a ne jmen construktorů v chainu...
Radim to nehrotit, JS není moc clone friendly, takže tak ...
Nejlíp neklonovat, ale ne vždy to jde.
Leckdy ale může pomoct udělat nějaký handle nebo proxy objekt, pokud je cílem originál nějak odstínit...
Vlastně JS ma ty prototypy tak zprasený,  že nejlíp je nepoužívat vubec a jet na delegační pattern.
Popřípadě pomocí klonovací knihovny a objektových literalu si udělat ten oop systém vlastní ...
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 22:13:15
Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

jako zdroj je uveden nějaký pseudovědecký článek o hovně. Nepsal jste ho vy? Jasně, že lze objekty i klonovat. Ale zrovna v JS to není nejběžnější způsob jejich vytváření a s prototypy to nemá nic společného. Object.create(foo) nic neklonuje.

Uz ste zmenili stanovisko z "nepise sa tam" na "pseudovedecky clanok o hovne". Ja som to nepisal, mna prototype-based programming zaujimalo len okrajovo ako moznost lepenia aspektov symetrickym sposobom.  Clanok nie je pseudovedecky, vyzera, ze je to z publikacie ktora vysla u springera o prototype-based programming, ale uznavam, ze dost davno v roku 1999. Predpokladam, ze ste odvtedy napisali clanok, ktory nezmysly vyvracia.
Název: Re:Dědičnost dnes
Přispěvatel: balki 20. 01. 2017, 22:20:23
Zas diskuze o klonování? To už jsme tady měli ...
JS ma oop systém hodně zprasenej, takže je tam hodně výkladů co je a není klon.
Obecně se ale bere za klon deep copy + shallow copy prototypu.
Jak tady někdo říkal, nejlíp by chtělo udělat deep copy i prototypu, to by zase ale rozbylo instanceof protože to se orientuje podle referencí a ne jmen construktorů v chainu...
Radim to nehrotit, JS není moc clone friendly, takže tak ...
Nejlíp neklonovat, ale ne vždy to jde.
Leckdy ale může pomoct udělat nějaký handle nebo proxy objekt, pokud je cílem originál nějak odstínit...
Vlastně JS ma ty prototypy tak zprasený,  že nejlíp je nepoužívat vubec a jet na delegační pattern.
Popřípadě pomocí klonovací knihovny a objektových literalu si udělat ten oop systém vlastní ...

Deep copy sa nerobi kvoli tomu, ze graf referencii nemusi byt zrovna jednoduchy, moze tam byt cyklus, alebo sa vytvorit klon privelkeho poctu objektov.  Nie je sposob, ako to spravne implementovat.
Název: Re:Dědičnost dnes
Přispěvatel: gll 20. 01. 2017, 23:58:39
Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

jako zdroj je uveden nějaký pseudovědecký článek o hovně. Nepsal jste ho vy? Jasně, že lze objekty i klonovat. Ale zrovna v JS to není nejběžnější způsob jejich vytváření a s prototypy to nemá nic společného. Object.create(foo) nic neklonuje.

Uz ste zmenili stanovisko z "nepise sa tam" na "pseudovedecky clanok o hovne". Ja som to nepisal, mna prototype-based programming zaujimalo len okrajovo ako moznost lepenia aspektov symetrickym sposobom.  Clanok nie je pseudovedecky, vyzera, ze je to z publikacie ktora vysla u springera o prototype-based programming, ale uznavam, ze dost davno v roku 1999. Predpokladam, ze ste odvtedy napisali clanok, ktory nezmysly vyvracia.

u JS příkladu na wikipedii je napsáno, že se jedná o způsob "ex nihilo". Vy jste tvrdil, že se jedná o klonování.
Název: Re:Dědičnost dnes
Přispěvatel: balki 21. 01. 2017, 00:15:15
Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

jako zdroj je uveden nějaký pseudovědecký článek o hovně. Nepsal jste ho vy? Jasně, že lze objekty i klonovat. Ale zrovna v JS to není nejběžnější způsob jejich vytváření a s prototypy to nemá nic společného. Object.create(foo) nic neklonuje.

Uz ste zmenili stanovisko z "nepise sa tam" na "pseudovedecky clanok o hovne". Ja som to nepisal, mna prototype-based programming zaujimalo len okrajovo ako moznost lepenia aspektov symetrickym sposobom.  Clanok nie je pseudovedecky, vyzera, ze je to z publikacie ktora vysla u springera o prototype-based programming, ale uznavam, ze dost davno v roku 1999. Predpokladam, ze ste odvtedy napisali clanok, ktory nezmysly vyvracia.

u JS příkladu na wikipedii je napsáno, že se jedná o způsob "ex nihilo". Vy jste tvrdil, že se jedná o klonování.

Este raz, existuju 2 sposoby vytvorenia objektu v prototype-based programming. Ex nihilo, alebo klonovanie. Ex nihilo znamena "z nicoho", teda, ze sa nadefinuje cely objekt a nic sa nepouzije znova. Klonovanie znamena, ze sa spravi reuse prototypu.

Naco je potom prototyp, ked sa podla vas vytvara "z nicoho", to nedava logiku.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 21. 01. 2017, 01:04:30
Zas diskuze o klonování? To už jsme tady měli ...
JS ma oop systém hodně zprasenej, takže je tam hodně výkladů co je a není klon.
Obecně se ale bere za klon deep copy + shallow copy prototypu.
Jak tady někdo říkal, nejlíp by chtělo udělat deep copy i prototypu, to by zase ale rozbylo instanceof protože to se orientuje podle referencí a ne jmen construktorů v chainu...
Radim to nehrotit, JS není moc clone friendly, takže tak ...
Nejlíp neklonovat, ale ne vždy to jde.
Leckdy ale může pomoct udělat nějaký handle nebo proxy objekt, pokud je cílem originál nějak odstínit...
Vlastně JS ma ty prototypy tak zprasený,  že nejlíp je nepoužívat vubec a jet na delegační pattern.
Popřípadě pomocí klonovací knihovny a objektových literalu si udělat ten oop systém vlastní ...

Deep copy sa nerobi kvoli tomu, ze graf referencii nemusi byt zrovna jednoduchy, moze tam byt cyklus, alebo sa vytvorit klon privelkeho poctu objektov.  Nie je sposob, ako to spravne implementovat.
Nesmysl.
Cykli nejsou problem.
Velký graf je problem programatora, ne filozofie.
Klonují se jen objekty kde to dává smysl, nikdo nebude klonovat root objektn např.
Klonování je třeba pro prototype based oop protože skrz klonování se v něm originálně tvoří objekty.
Ex nihilo je jen pomocná metoda.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 21. 01. 2017, 01:13:41
Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

jako zdroj je uveden nějaký pseudovědecký článek o hovně. Nepsal jste ho vy? Jasně, že lze objekty i klonovat. Ale zrovna v JS to není nejběžnější způsob jejich vytváření a s prototypy to nemá nic společného. Object.create(foo) nic neklonuje.

Uz ste zmenili stanovisko z "nepise sa tam" na "pseudovedecky clanok o hovne". Ja som to nepisal, mna prototype-based programming zaujimalo len okrajovo ako moznost lepenia aspektov symetrickym sposobom.  Clanok nie je pseudovedecky, vyzera, ze je to z publikacie ktora vysla u springera o prototype-based programming, ale uznavam, ze dost davno v roku 1999. Predpokladam, ze ste odvtedy napisali clanok, ktory nezmysly vyvracia.

u JS příkladu na wikipedii je napsáno, že se jedná o způsob "ex nihilo". Vy jste tvrdil, že se jedná o klonování.

Este raz, existuju 2 sposoby vytvorenia objektu v prototype-based programming. Ex nihilo, alebo klonovanie. Ex nihilo znamena "z nicoho", teda, ze sa nadefinuje cely objekt a nic sa nepouzije znova. Klonovanie znamena, ze sa spravi reuse prototypu.

Naco je potom prototyp, ked sa podla vas vytvara "z nicoho", to nedava logiku.
Dava to logiku. Prototyp je možno brát i jako defaultni delegat pro nezname zpravy (tak je to v selfu pokud se nepletu).
Ex nihilo a klonovani je strategie tvorby objektu, pricemz v případě klonování je klonovaný prototyp svého klona.
Všechny přístupy je možno libovolně míchat, koneckonců jsou to jen objekty s nějakými sloty, nic víc, žádný třídní balast.

Obávám se že tuto problematiku jsi zatím plně neovlád, tak prosím nemať čtenáře, zrovna tohle vlákno je extrémně zajímavé.
Název: Re:Dědičnost dnes
Přispěvatel: balki 21. 01. 2017, 01:55:35
Citace
In prototype-based languages there are no explicit classes. Objects inherit directly from other objects through a prototype property. The prototype property is called prototype in Self, proto in Io and __proto__ in JavaScript. There are two methods of constructing new objects: ex nihilo ("from nothing") object creation or through cloning an existing object. The former is supported through some form of object literal, declarations where objects can be defined at runtime through special syntax such as {...} and passed directly to a variable. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.[4]

jako zdroj je uveden nějaký pseudovědecký článek o hovně. Nepsal jste ho vy? Jasně, že lze objekty i klonovat. Ale zrovna v JS to není nejběžnější způsob jejich vytváření a s prototypy to nemá nic společného. Object.create(foo) nic neklonuje.

Uz ste zmenili stanovisko z "nepise sa tam" na "pseudovedecky clanok o hovne". Ja som to nepisal, mna prototype-based programming zaujimalo len okrajovo ako moznost lepenia aspektov symetrickym sposobom.  Clanok nie je pseudovedecky, vyzera, ze je to z publikacie ktora vysla u springera o prototype-based programming, ale uznavam, ze dost davno v roku 1999. Predpokladam, ze ste odvtedy napisali clanok, ktory nezmysly vyvracia.

u JS příkladu na wikipedii je napsáno, že se jedná o způsob "ex nihilo". Vy jste tvrdil, že se jedná o klonování.

Este raz, existuju 2 sposoby vytvorenia objektu v prototype-based programming. Ex nihilo, alebo klonovanie. Ex nihilo znamena "z nicoho", teda, ze sa nadefinuje cely objekt a nic sa nepouzije znova. Klonovanie znamena, ze sa spravi reuse prototypu.

Naco je potom prototyp, ked sa podla vas vytvara "z nicoho", to nedava logiku.
Dava to logiku. Prototyp je možno brát i jako defaultni delegat pro nezname zpravy (tak je to v selfu pokud se nepletu).
Ex nihilo a klonovani je strategie tvorby objektu, pricemz v případě klonování je klonovaný prototyp svého klona.
Všechny přístupy je možno libovolně míchat, koneckonců jsou to jen objekty s nějakými sloty, nic víc, žádný třídní balast.

Obávám se že tuto problematiku jsi zatím plně neovlád, tak prosím nemať čtenáře, zrovna tohle vlákno je extrémně zajímavé.

Ah, co tu este robim, bavte sa tu bezo mna, tu nie je nadej na rozumnu debatu.
Název: Re:Dědičnost dnes
Přispěvatel: balki 21. 01. 2017, 02:02:55
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf
Název: Re:Dědičnost dnes
Přispěvatel: balki 21. 01. 2017, 02:21:56
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf

Ok uz som si pozrel viac zdrojov. V prototype based porgramovani je mozno vytvorit objekt troma sposobmi

Co mi tu gll a cumil motali ze ex nihilo obsahuje prototyp bola samozrejme hlupost. Dakujem, aspon som si ozrejmil veci, ze tam pristupuje este delegacia. (Pricom v niektorej literature este aj tu delegaciu povazuju za klonovanie)
Název: Re:Dědičnost dnes
Přispěvatel: gll 21. 01. 2017, 11:46:00
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf

Ok uz som si pozrel viac zdrojov. V prototype based porgramovani je mozno vytvorit objekt troma sposobmi
  • Ex nihilo - vytvori sa novy objekt
  • Delegaciou  - spravi sa shallow copy prototypu
  • Klonovanim  - spravi sa deep copy prototypu

Co mi tu gll a cumil motali ze ex nihilo obsahuje prototyp bola samozrejme hlupost. Dakujem, aspon som si ozrejmil veci, ze tam pristupuje este delegacia. (Pricom v niektorej literature este aj tu delegaciu povazuju za klonovanie)

Každý, kdo prakticky programuje v JS, si pod klonováním představuje něco jiného než kopii prototypu. Kopírují se vlastnosti samotného objektu, prototyp se většinou jen předává.

Žádná shallow copy prototypu při vytváření nevzniká. To je princip prototypového OOP.

Z vašich odpovědí je jasné, že javascript neznáte. Zkuste si místo vědeckých článků přečíst tutoriál od Mozilly a vyzkoušejte si příklady v browseru.
Název: Re:Dědičnost dnes
Přispěvatel: gll 21. 01. 2017, 11:51:32
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf

Čumil narozdíl od vás ví o čem mluví. Není možné obecně teoretizovat o nějaké skupině jazyků, bez toho, abyste pořádně znal alespoň jeden jazyk z té skupiny a uměl ho prakticky používat.
Název: Re:Dědičnost dnes
Přispěvatel: balki 21. 01. 2017, 16:59:18
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf

Čumil narozdíl od vás ví o čem mluví. Není možné obecně teoretizovat o nějaké skupině jazyků, bez toho, abyste pořádně znal alespoň jeden jazyk z té skupiny a uměl ho prakticky používat.

Radim vam, naucit sa citat a pocuvat, dost to pomaha, aj vam aj cumilovi. Ono je kopec fachidiotov, co si idu svoje, lebo to uz robia 100 rokov.
Název: Re:Dědičnost dnes
Přispěvatel: balki 21. 01. 2017, 17:10:24
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf

Ok uz som si pozrel viac zdrojov. V prototype based porgramovani je mozno vytvorit objekt troma sposobmi
  • Ex nihilo - vytvori sa novy objekt
  • Delegaciou  - spravi sa shallow copy prototypu
  • Klonovanim  - spravi sa deep copy prototypu

Co mi tu gll a cumil motali ze ex nihilo obsahuje prototyp bola samozrejme hlupost. Dakujem, aspon som si ozrejmil veci, ze tam pristupuje este delegacia. (Pricom v niektorej literature este aj tu delegaciu povazuju za klonovanie)

Každý, kdo prakticky programuje v JS, si pod klonováním představuje něco jiného než kopii prototypu. Kopírují se vlastnosti samotného objektu, prototyp se většinou jen předává.

Žádná shallow copy prototypu při vytváření nevzniká. To je princip prototypového OOP.

Z vašich odpovědí je jasné, že javascript neznáte. Zkuste si místo vědeckých článků přečíst tutoriál od Mozilly a vyzkoušejte si příklady v browseru.

Ok, je tam stale ten delegat, ale jednotlive atributy sa prekryvaju. Cize je to prakticky jedno. Vasa fachidiocia mi fakt uz pripada smiesna.

Kód: [Vybrat]
> a = {}
{}
> a.lala = 5
5
> b = Object.create(a)
{}
> b.lala
5
> a.lala = 6
6
> b.lala
6
> b.lala = 7
7
> a.lala
6
Název: Re:Dědičnost dnes
Přispěvatel: Polymath 21. 01. 2017, 19:24:17
Pre cumila. Tu je literatura, prosim hladajte ex nihilo a vzdelavajte sa:

http://www.lirmm.fr/~dony/postscript/proto-book.pdf

Čumil narozdíl od vás ví o čem mluví. Není možné obecně teoretizovat o nějaké skupině jazyků, bez toho, abyste pořádně znal alespoň jeden jazyk z té skupiny a uměl ho prakticky používat.

Radim vam, naucit sa citat a pocuvat, dost to pomaha, aj vam aj cumilovi. Ono je kopec fachidiotov, co si idu svoje, lebo to uz robia 100 rokov.
Vzhledem k jejich způsobu vyjádřování ("analíza", "rozbylo se") bych vypustil předponu "fach-".
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 14:11:42
Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Tak vidíš a jaký je to bastl. Dělají v tom jen lopaty, které nikdy nepochopí programování. Prostě mi přijde divné, proč používáš OOP pro nějaký paskvil, který je mrtvý a zůstal maximálně u skriptovacích jazyků na minivěci.

Takže znakem "pure" OOP je co? Normální OOP totiž vypadá daleko lépe a pure znamená horší, což obvykle bývá naopak.

Bastl? Těžko říct. Nebýt toho zkurveného nefunkčního zapouzdření ve spojení s prototypy, mohl to být docela slušný jazyk. Ale jestli tu chcete protežovat Javu, tak ta čisté OP též nesplňuje.

Vlastnosti čistého OP jsou: Identita, zapouzdření, skládání, delegování, posílání zpráv. Vše ostatní (dědičnost, mixiny, ...) je navíc a původní koncept neovlivňuje.
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 14:23:57
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.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 22. 01. 2017, 14:26:54
Tak pozor, zrovna Javascript je docela blízký Smalltalku - má jmenný polymorfismus, (v podstatě nepoužitelné) zapouzdření a pozdní vazbu. Mimoto velice silnou reflexivitu.

Tak vidíš a jaký je to bastl. Dělají v tom jen lopaty, které nikdy nepochopí programování. Prostě mi přijde divné, proč používáš OOP pro nějaký paskvil, který je mrtvý a zůstal maximálně u skriptovacích jazyků na minivěci.

Takže znakem "pure" OOP je co? Normální OOP totiž vypadá daleko lépe a pure znamená horší, což obvykle bývá naopak.

Bastl? Těžko říct. Nebýt toho zkurveného nefunkčního zapouzdření ve spojení s prototypy, mohl to být docela slušný jazyk. Ale jestli tu chcete protežovat Javu, tak ta čisté OP též nesplňuje.

Vlastnosti čistého OP jsou: Identita, zapouzdření, skládání, delegování, posílání zpráv. Vše ostatní (dědičnost, mixiny, ...) je navíc a původní koncept neovlivňuje.

Jsou tam nové verze jako v ostatních jazycích? Protože jsem ho znal někdy v roce 98, což na skriptování docela šlo. Pak jsem to zkoušel o něco později a o moc lepší to nebylo.

Java splňuje normání OOP a to tvoje pure nikdo nepotřebuje, ale chtěl jsem vědět, o co přicházím :)

Ahaaa, takže vlastně všechno máme, ne?
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 14:34:58
Javascript...

Objekty se vytváří konstruktorem. Nic se při tom neklonuje. Prototyp zůstává jen jeden.

No, ono je to trochu schizofreničtější - tím konstruktorem je obyčejná, prašivá funkce, jejíž kontext se po vzniku použije jako objekt, ale to pouze při použití klíčového slova new. Samotné klonování objektu sice nějak ukvedlat jde, ale samotný jazyk na to přímočarou metodu nemá - je třeba to řešit docela složitě. Znalí vědí. Takže jako teda nic moc. Tohle je jedno z dalších implementačních zklamání jinak dobře myšleného jazyku.
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 14:49:08
...jaký obsah má čtverec, kterému nastavím strany 2 a 3? ... do databáze perzistuji hovadinu...

JASNĚ jsem uvedl, že třída čtverce zajišťuje shodu délek stran a i b, tudíž není možno mít a=2 a b=3. Data pro uložení pak buďto poskytuje sama instance čtverce, takže dostačuje jedna strana, nebo je řešeno v mapovači čtverce do DB, který pro uložení čtverce vede jen jednu stranu.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 22. 01. 2017, 14:54:52
...jaký obsah má čtverec, kterému nastavím strany 2 a 3? ... do databáze perzistuji hovadinu...

JASNĚ jsem uvedl, že třída čtverce zajišťuje shodu délek stran a i b, tudíž není možno mít a=2 a b=3. Data pro uložení pak buďto poskytuje sama instance čtverce, takže dostačuje jedna strana, nebo je řešeno v mapovači čtverce do DB, který pro uložení čtverce vede jen jednu stranu.

Pocitam, ze se porad bavime o mutable variante, jinak je to trivialni zalezitost?

A jak se v tom pripade chova tahle posloupnost prikazu?

Kód: [Vybrat]
final Obdelnik o = new Ctverec(1)
o.setA(2)
o.setB(3)
print o.obsah()

?
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 15:01:38

v tom článku na wikipedii se o žádném klonování nepíše. O klonování objektů v javascriptu si přečtěte třeba zde:

http://stackoverflow.com/questions/728360/how-do-i-correctly-clone-a-javascript-object

Taky si myslím, že to tam mají nějaké pošukané - to, co popisují, je "prototypování", neboli vytvoření objektu s vazbou na svůj uvedený prototyp pro účely delegování. Klonování je vytvoření prosté kopie, která se mimo identity ve všem shoduje s originálem, ale nemá na něj jakoukoliv vazbu - uvedeno v odkazu na Stackoverflow.
Ale možná ty termíny taky chybně chápu.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 15:03:28
Kód: [Vybrat]
final Kruh k = new Kruh(1)
k.setPrumer(2)
k.setPolomer(3)
print k.obsah()
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 22. 01. 2017, 15:13:33
Kód: [Vybrat]
final Kruh k = new Kruh(1)
k.setPrumer(2)
k.setPolomer(3)
print k.obsah()

Nebudes tomu verit, ale je to uplne jiny pripad. Chces si za domaci ukol vymyslet, v cem je rozdil, nebo radeji napovedu? ;)
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 15:29:57
Kód: [Vybrat]
final Kruh k = new Kruh(1)
k.setPrumer(2)
k.setPolomer(3)
print k.obsah()

Nebudes tomu verit, ale je to uplne jiny pripad. Chces si za domaci ukol vymyslet, v cem je rozdil, nebo radeji napovedu? ;)
To je záměr, u tohoto případu se totiž nikdo neptá, jak se to bude chovat.
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 15:31:58
Omlouvám se tedy za nepochopení termínů, tomu, čemu říkám "prototypování", je tedy klonování.


Každý, kdo prakticky programuje v JS, si pod klonováním představuje něco jiného než kopii prototypu. Kopírují se vlastnosti samotného objektu, prototyp se většinou jen předává.

Žádná shallow copy prototypu při vytváření nevzniká. To je princip prototypového OOP.

Takhle si "prototypování" taky představuju - stavy musí mít objekt vlastní, ale metody je možno sdílet v prototypu (obdobně jako v třídách). Proto taky v případě přepisu metody v prototypu se změní chování všech klonů. Oproti třídně-instanční implementaci OOP je v Javascriptu (nevím, jak jinde) ale jeden FATÁLNÍ implementační problém - metoda prototypu (při spuštění) nevidí dovnitř klonu, ale vidí jej pouze zvenku (tj. jako jakýkoliv jiný objekt), tj. jen veřejné vlastnosti a metody!!! Tím padá použití zapouzdření v modelech a tím i použití Javascriptu na vážné modelování. Toto je okolnost, ke které bych rád slyšel od někoho, kdo Javascriptu OPRAVDU(!) rozumí, komentář.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 22. 01. 2017, 15:36:14
Kód: [Vybrat]
final Kruh k = new Kruh(1)
k.setPrumer(2)
k.setPolomer(3)
print k.obsah()

Nebudes tomu verit, ale je to uplne jiny pripad. Chces si za domaci ukol vymyslet, v cem je rozdil, nebo radeji napovedu? ;)
To je záměr, u tohoto případu se totiž nikdo neptá, jak se to bude chovat.

Neni to zamer ale nepochopeni.

Ten kruh neni potomek nejake jine tridy T, kde je jejim kontraktem nezavisle setPrumer a setPolomer.

Zkus si prepsat ten priklad pro Kruh a Elipsu a uvidis...
Název: Re:Dědičnost dnes
Přispěvatel: Cikáda 22. 01. 2017, 15:43:42
@SB - V sedmé přednášce to myslím i řešil (ale už jsem to nějakou dobu neviděl) - https://slideslive.com/s/ondrej-zara-675

@Javaman() - Nevím, jestli na tebe má vůbec cenu reagovat, ale u JS je venku ES6 a ten jazyk se vyvíjí... hodně rychle.
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 15:51:52

Jsou tam nové verze jako v ostatních jazycích? Protože jsem ho znal někdy v roce 98, což na skriptování docela šlo. Pak jsem to zkoušel o něco později a o moc lepší to nebylo.

Java splňuje normání OOP a to tvoje pure nikdo nepotřebuje, ale chtěl jsem vědět, o co přicházím :)

Ahaaa, takže vlastně všechno máme, ne?

Javascript (JS) má novou verzi, teď myslím 7, ale mimo (ne moc povedeného) pokusu o řešení asynchronních operací jsou tam jen pičoviny typu pseudotřídy.
Na takové to jednoduché skriptování je JS supr, ale na modelování velké domény to dře.

No, mně by se to pure hodně hodilo, např. takové smalltalkové doesNotUnderstand je nenahraditelné. Javascript měl něco pdobného (__noSuchMethod__), ale už je to nahrazeno komplikovaným Proxy (a kdoví, zda to vůbec funguje).

...Normální OOP totiž vypadá daleko lépe a pure znamená horší, což obvykle bývá naopak.

Tak já tady dlouze vysvětluju, že v Javě a C# a dalších nefunguje posílání zpráv, tudíž rozhodování na straně cílového objektu padá, a vy vzápětí napíšete, že "normální OOP" (tj. např. v té vaší Javě) vypadá daleko lépe. Zaprvé matně tuším, co znamená daleko lépe, zadruhé to je deklarativní prohlášení a je třeba jej podložit argumenty, jinak je bezcenné. Já už svoje tvrzení doložil.
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 16:00:40
Pocitam, ze se porad bavime o mutable variante, jinak je to trivialni zalezitost?

A jak se v tom pripade chova tahle posloupnost prikazu?

Kód: [Vybrat]
final Obdelnik o = new Ctverec(1)
o.setA(2)
o.setB(3)
print o.obsah()

?

Jasně, mutable.
Konstruktor i metody setA i setB nastavují vždy obě strany, protože musejí dodržet podmínku shody stran. Vzniklý čtverec má velikost 1 (obsah 1), po setA(2) má čtverec velikost 2 (obsah 4), po setB(3) má čtverec velikost 3 (obsah 3x3=9).
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 22. 01. 2017, 16:03:14
@SB - V sedmé přednášce to myslím i řešil (ale už jsem to nějakou dobu neviděl) - https://slideslive.com/s/ondrej-zara-675

@Javaman() - Nevím, jestli na tebe má vůbec cenu reagovat, ale u JS je venku ES6 a ten jazyk se vyvíjí... hodně rychle.

Tak někdo začal pomlouvat OOP v Javě, víš co :D OK, dík za info. Jsem si říkal, že by to bylo divný, pokud by to bylo stále stejné.


Jsou tam nové verze jako v ostatních jazycích? Protože jsem ho znal někdy v roce 98, což na skriptování docela šlo. Pak jsem to zkoušel o něco později a o moc lepší to nebylo.

Java splňuje normání OOP a to tvoje pure nikdo nepotřebuje, ale chtěl jsem vědět, o co přicházím :)

Ahaaa, takže vlastně všechno máme, ne?

Javascript (JS) má novou verzi, teď myslím 7, ale mimo (ne moc povedeného) pokusu o řešení asynchronních operací jsou tam jen pičoviny typu pseudotřídy.
Na takové to jednoduché skriptování je JS supr, ale na modelování velké domény to dře.

No, mně by se to pure hodně hodilo, např. takové smalltalkové doesNotUnderstand je nenahraditelné. Javascript měl něco pdobného (__noSuchMethod__), ale už je to nahrazeno komplikovaným Proxy (a kdoví, zda to vůbec funguje).

...Normální OOP totiž vypadá daleko lépe a pure znamená horší, což obvykle bývá naopak.

Tak já tady dlouze vysvětluju, že v Javě a C# a dalších nefunguje posílání zpráv, tudíž rozhodování na straně cílového objektu padá, a vy vzápětí napíšete, že "normální OOP" (tj. např. v té vaší Javě) vypadá daleko lépe. Zaprvé matně tuším, co znamená daleko lépe, zadruhé to je deklarativní prohlášení a je třeba jej podložit argumenty, jinak je bezcenné. Já už svoje tvrzení doložil.

Ahaaa, OK. Tak to je fajn.

Přijde mi, že spíše hledáš něco více dynamického na bastlení. Cokoli dynamického je z principu špatné u velkých věcí. Proto preferuji Javu. Samozřejmě nepoužívám skoro reflexi a podobné nesmysly, protože tím to celé zkurvíš.

Takže mi přijde, že máš rád hodně dynamické věci a pak se ti líbí i OOP, které se nepoužívá.

Chápu, v poho. Nemusíš tomu věřit :)
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 16:05:37
Kód: [Vybrat]
final Kruh k = new Kruh(1)
k.setPrumer(2)
k.setPolomer(3)
print k.obsah()

Nebudes tomu verit, ale je to uplne jiny pripad. Chces si za domaci ukol vymyslet, v cem je rozdil, nebo radeji napovedu? ;)
To je záměr, u tohoto případu se totiž nikdo neptá, jak se to bude chovat.

Neni to zamer ale nepochopeni.

Ten kruh neni potomek nejake jine tridy T, kde je jejim kontraktem nezavisle setPrumer a setPolomer.

Zkus si prepsat ten priklad pro Kruh a Elipsu a uvidis...

Pan Honza nedokazoval odvozování kruhu, ale že nastavení velikosti a výpočet jsou vnitřní záležitostí objektu.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 22. 01. 2017, 16:06:11
Pocitam, ze se porad bavime o mutable variante, jinak je to trivialni zalezitost?

A jak se v tom pripade chova tahle posloupnost prikazu?

Kód: [Vybrat]
final Obdelnik o = new Ctverec(1)
o.setA(2)
o.setB(3)
print o.obsah()

?

Jasně, mutable.
Konstruktor i metody setA i setB nastavují vždy obě strany, protože musejí dodržet podmínku shody stran. Vzniklý čtverec má velikost 1 (obsah 1), po setA(2) má čtverec velikost 2 (obsah 4), po setB(3) má čtverec velikost 3 (obsah 3x3=9).

A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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).
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 16:35:24

Přijde mi, že spíše hledáš něco více dynamického na bastlení. Cokoli dynamického je z principu špatné u velkých věcí. Proto preferuji Javu. Samozřejmě nepoužívám skoro reflexi a podobné nesmysly, protože tím to celé zkurvíš.

Takže mi přijde, že máš rád hodně dynamické věci a pak se ti líbí i OOP, které se nepoužívá.

Na bastlení stačí kdeco, hledám jazyk pro obchodní aplikace.

Pane Javamane, co odpověď, to plno nepodložených, obecných tvrzení - Java je supr, tohle OOP se nepoužívá, reflexe je na hovno... Takhle by to mohlo jít hodiny - vy něco plácnete, já budu dokazovat a argumentovat. Proto se určitě nebudete zlobit, když už na vaše podobné dotazy (a lepší nečekám) nebudu reagovat, je tu pár lidí, od kterých se něco skutečně můžu dozvědět. Vaše dojmy mi moji práci neusnadní.
Název: Re:Dědičnost dnes
Přispěvatel: SB 22. 01. 2017, 16:36:38
A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Který to je?
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 22. 01. 2017, 16:40:27
A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Který to je?

Uz jsem to sem psal minimalne dvakrat, z toho minimalne jednou v pseudokodu.

Je jich dost. Ze zmena a nema vliv na b. Ze zdvojnasobeni a zdvojnasobi obsah. Ze zdvojnasobeni b zdvojnasobi obsah...

Dost mne desi, ze se lidi mohou x stranek dohadovat o takovych zakladech, jako je aplikace LSP na hierarchii ctvercu a obdelniku.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 22. 01. 2017, 16:43:48

Přijde mi, že spíše hledáš něco více dynamického na bastlení. Cokoli dynamického je z principu špatné u velkých věcí. Proto preferuji Javu. Samozřejmě nepoužívám skoro reflexi a podobné nesmysly, protože tím to celé zkurvíš.

Takže mi přijde, že máš rád hodně dynamické věci a pak se ti líbí i OOP, které se nepoužívá.

Na bastlení stačí kdeco, hledám jazyk pro obchodní aplikace.

Pane Javamane, co odpověď, to plno nepodložených, obecných tvrzení - Java je supr, tohle OOP se nepoužívá, reflexe je na hovno... Takhle by to mohlo jít hodiny - vy něco plácnete, já budu dokazovat a argumentovat. Proto se určitě nebudete zlobit, když už na vaše podobné dotazy (a lepší nečekám) nebudu reagovat, je tu pár lidí, od kterých se něco skutečně můžu dozvědět. Vaše dojmy mi moji práci neusnadní.

V pohodě, jsem rád, že opravdu reaguješ na věci tady.

Ale zase tak do hloubky jsem jít nechtěl. Pokud máš rád cokoli dynamického, tak si nemůžeme rozumět. Znám pár lidí, kteří dělají i dynamickou Javu a jsou to supersračky, protože to ani nejde debugovat. Aplikace má miliardy stavů, které nikdo nikdy neotestuje, protože jsem přece cool a dynamičtí :D
Název: Re:Dědičnost dnes
Přispěvatel: noef 22. 01. 2017, 17:41:16
Jen tak ze zajimavosti, kdyz se uz tady resi ta dedicnost, tak se zeptam. Akka actori (Scala) mi pripadaji dost podobni jako ty objekty ve Smalltalku, je tomu tak? O Smalltalku jsem videl jen kratkou prednasku, takze opravdu moc netusim, ale napr. to posilani zprav a "netypovost" actoru pusobi dost podobne.

Osobne taky preferuji staticke veci typu Haskell nebo Scala (paradoxne jsem donedavna v praci delal primarne v JS :D, ted alespon s tim TypeScriptem jsem se trochu priblizil statickemu svetu).

Vetsina reflexe v Jave (i Scale) je dost draha na vykon a samozrejmne jak pise Javaman(), obtizne se to ladi, udrzuje, atd.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 17:59:17
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?
Název: Re:Dědičnost dnes
Přispěvatel: balki 22. 01. 2017, 18:36:17
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Java sa neladi za behu. Je mozne ponastavovat rozne konfiguracne parametre, ale to je tak asi vsetko. Odvodeniny smalltalk-80 su runtime a IDE v jednom (macko-pes s kuchynskym drezom), takze logicky ladenie "za behu" je tam jednoduche. Kedze sa tam "za behu" aj programuje, skor je problem kodit s vypnutym rutime. Java a smalltalk su jazyky s inym urcenim, moc to porovnavat nejde.
Název: Re:Dědičnost dnes
Přispěvatel: gll 22. 01. 2017, 18:39:38
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 18:43:50
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Java sa neladi za behu. Je mozne ponastavovat rozne konfiguracne parametre, ale to je tak asi vsetko. Odvodeniny smalltalk-80 su runtime a IDE v jednom (macko-pes s kuchynskym drezom), takze logicky ladenie "za behu" je tam jednoduche. Kedze sa tam "za behu" aj programuje, skor je problem kodit s vypnutym rutime. Java a smalltalk su jazyky s inym urcenim, moc to porovnavat nejde.
Díky, já to vím, já si také myslím, že to srovnávat nelze. Já stojím na straně Smalltalku, ale vidím už několikátý příspěvek, kde někdo tvrdí, že ladění v dynamických jazycích je údajně obtížné, přičemž právě např. v Javě to za běhu ani možné není...
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 18:45:54
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?
Ano, s tím rozdílem, že Smalltalk to umí už 40 let, zatímco Lightable se tváří jako novinka...
Název: Re:Dědičnost dnes
Přispěvatel: balki 22. 01. 2017, 18:49:48
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Java sa neladi za behu. Je mozne ponastavovat rozne konfiguracne parametre, ale to je tak asi vsetko. Odvodeniny smalltalk-80 su runtime a IDE v jednom (macko-pes s kuchynskym drezom), takze logicky ladenie "za behu" je tam jednoduche. Kedze sa tam "za behu" aj programuje, skor je problem kodit s vypnutym rutime. Java a smalltalk su jazyky s inym urcenim, moc to porovnavat nejde.
Díky, já to vím, já si také myslím, že to srovnávat nelze. Já stojím na straně Smalltalku, ale vidím už několikátý příspěvek, kde někdo tvrdí, že ladění v dynamických jazycích je údajně obtížné, přičemž právě např. v Javě to za běhu ani možné není...

Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 18:59:35
Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.
To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...
Název: Re:Dědičnost dnes
Přispěvatel: gll 22. 01. 2017, 19:00:43
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?
Ano, s tím rozdílem, že Smalltalk to umí už 40 let, zatímco Lightable se tváří jako novinka...

je to otázka IDE a ne jazyka. Hodí se to jen pro některé typy programů.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 22. 01. 2017, 19:10:09
Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.
To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

Nikdo to nepotřebuje :) JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 19:33:56
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?
Ano, s tím rozdílem, že Smalltalk to umí už 40 let, zatímco Lightable se tváří jako novinka...

je to otázka IDE a ne jazyka. Hodí se to jen pro některé typy programů.
No jistě, ani Java od Sun/Oracle není jediná existující implementace Javy. Ale IDE jsou hromady. Jazyk a jeho implementaci tady ale rozlišuje málokdo. Zůstávám u existujících implementací a IDE a netvrdím, že by nemohla existovat Java, kde to bude fungovat podobně... a kde se to bude hodit na všechny programy, a ne jen na některé typy...

Nikdo to nepotřebuje :) JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.
Kdyby to v Javě šlo udělat snadno, tak by to podle mě používali všichni. A nemyslím tím překompilování a zavedení nějaké Java třídy. Myslím tím např. doplnění nové chybějící metody na server, který zastavený čeká na breakpointu, zatímco si vyhozenou výjímku serializuji pro analýzu na lokální disk, a po otestování nechám server pokračovat od místa kde přestal. Java i Python mně vysype maximálně stacktrace...
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 22. 01. 2017, 19:36:05
Ne, fakt ne. To je tak na hraní při studiu. Kdyby to někdo chtěl, tak to dávno Java má. To je maličkost to přidat do JVM.
Název: Re:Dědičnost dnes
Přispěvatel: gll 22. 01. 2017, 19:48:42
Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.
To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

JRebel je placený SW a neumí nic co by nebylo v jiných jazycích triviální. isend-mode v Emacsu umí posílat změněný kód do debuggeru už dávno.

Název: Re:Dědičnost dnes
Přispěvatel: gll 22. 01. 2017, 19:54:05
automatické reloadování webové aplikace považuji za samozřejmost.
Název: Re:Dědičnost dnes
Přispěvatel: gll 22. 01. 2017, 20:01:24
Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?
Ano, s tím rozdílem, že Smalltalk to umí už 40 let, zatímco Lightable se tváří jako novinka...

je to otázka IDE a ne jazyka. Hodí se to jen pro některé typy programů.
No jistě, ani Java od Sun/Oracle není jediná existující implementace Javy. Ale IDE jsou hromady. Jazyk a jeho implementaci tady ale rozlišuje málokdo. Zůstávám u existujících implementací a IDE a netvrdím, že by nemohla existovat Java, kde to bude fungovat podobně... a kde se to bude hodit na všechny programy, a ne jen na některé typy...

Nemyslel jsem zrovna Javu. Light Table to umí pro Clojure, Python a JavaScript. Nezkoušel jsem to, ale asi tam budou omezení.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 22. 01. 2017, 20:06:13
Nemyslel jsem zrovna Javu. Light Table to umí pro Clojure, Python a JavaScript. Nezkoušel jsem to, ale asi tam budou omezení.
Jojo, já dávám taky Javu jenom jako příklad. Nicméně taková IDE už dnes běží i online ve webovém prohlížeči, třeba i pro assembler. Nicméně jsme asi trochu odbočili od těch obdélníků, čtverců... a kruhů! Pardon, také za to můžu.
Název: Re:Dědičnost dnes
Přispěvatel: balki 22. 01. 2017, 20:29:49
Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.
To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

Nikdo to nepotřebuje :) JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.

Hlavne uz nie je zvyk robit obrovske monolity, uz nejake to desatrocie je popularna servisne orientovana architektura. 
Název: Re:Dědičnost dnes
Přispěvatel: gll 22. 01. 2017, 21:53:11
Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.
To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

Nikdo to nepotřebuje :) JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.

nejsou malé projekty pro lopaty?
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 22. 01. 2017, 21:58:34
To jo, ale jde o to, že ty stavíš větší projekty z malých. Takže lopaty dělají třeba JS a nějaké CSS a ty koordinuješ vše podstatné. Všechno musí sedět, ale určitě není moc potřeba to, z čeho je tady Honza na větvi.
Název: Re:Dědičnost dnes
Přispěvatel: ava 23. 01. 2017, 12:20:56
Jen tak ze zajimavosti, kdyz se uz tady resi ta dedicnost, tak se zeptam. Akka actori (Scala) mi pripadaji dost podobni jako ty objekty ve Smalltalku, je tomu tak? O Smalltalku jsem videl jen kratkou prednasku, takze opravdu moc netusim, ale napr. to posilani zprav a "netypovost" actoru pusobi dost podobne.

Osobne taky preferuji staticke veci typu Haskell nebo Scala (paradoxne jsem donedavna v praci delal primarne v JS :D, ted alespon s tim TypeScriptem jsem se trochu priblizil statickemu svetu).

Vetsina reflexe v Jave (i Scale) je dost draha na vykon a samozrejmne jak pise Javaman(), obtizne se to ladi, udrzuje, atd.

Ne, actoři ve scale jsou asynchronni, smalltalkovske posílání zpráv je úplně obyčejné synchronní volání metody jako třeba v pythonu, akorát se to jinak (a podle mě lépe) jmenuje, tedy alespoň od smalltalku 80, je možné, že někdy předtím byla ta sémantika jiná, přeci jen smalltalk byl ze začátku hlavně výzkumný jazyk, který se dost měnil....

Jinak jasný, ladění ve smalltalku je to nejlepší co jsem kdy zažil, a teďka u ostatních jazyků šíleně nadávám když musím pouštět debugger (už to, že ho vůbec musím pouštět :)
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 23. 01. 2017, 13:06:26
A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Člověče, vy jste si o tom někde něco přečetl, ale totálně vám chybí cit pro praktickou aplikaci. Substituční princip není žádné posvátné tele. Naproti tomu, zákaz provádět mimo objekt něco, co je v kompetenci toho objektu, nebo nepředpokládat o vnitřních vlastnostech toho objektu něco, co není explicitně specifikováno, se tomu svatému teleti blíží mnohem více.
Dovedu si představit spoustu aplikací, kde by čtverec, jakožto potomek obdélníku (a jiné analogické aplikace), měl smysl, a jiné, kde by to naopak nešlo. Že má obdélník, jakožto abstraktní geometrický útvar, dvě nezávislé strany, je jedna věc, ale že by objekt obdélník, jakožto prostředek nějakého konkrétního objektového modelu, musel mít bezpodmínečně stejnou vlastnost, to už tedy zdaleka tak zřejmé není. Jestliže někde budu chtít mít obdélníky se zaručenou vlastností, že mají poměr stran 2:1, tak se mi taková definice hodí. Protože budu mít zaručen tento poměr a přitom na takový obdélník mohu aplikovat vše, co platí pro obecný obdélník. Pokud bude obecný obdélník disponovat metodou např. pro nastavení jedné strany na základě zadaného obsahu a druhé strany, tak nastane problém. Ale tohle záleží na konkrétním modelu. Nejde o tom říci nic obecně. Snad jen kromě toho, že kdybych něco takového potřeboval, mělo by to opravdu být součástí toho objektu, ať už obecného obdélníku, nebo nějakého jeho potomka (podle potřeby), ale rozhodně bych to neměl počítat někde mimo, jak tu naznačujete, protože vztahy mezi stranami, obsahem, úhlopříčkami a dalšími vlastnosti obdélníku jsou vnitřními záležitostmi toho objektu.
A ještě jednou zdůrazňuji rozdíl mezi geometrickým pojmem obdélník a obdélníkem jakožto prostředkem objektového modelu, kdyby vás opět napadlo jak zaseklá deska blábolit cosi o porušení kontraktu obdélníku (o němž nic nevíte, protože ho tu nikdo nespecifikoval).
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 23. 01. 2017, 13:21:19
A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Člověče, vy jste si o tom někde něco přečetl, ale totálně vám chybí cit pro praktickou aplikaci. Substituční princip není žádné posvátné tele. Naproti tomu, zákaz provádět mimo objekt něco, co je v kompetenci toho objektu, nebo nepředpokládat o vnitřních vlastnostech toho objektu něco, co není explicitně specifikováno, se tomu svatému teleti blíží mnohem více.
Dovedu si představit spoustu aplikací, kde by čtverec, jakožto potomek obdélníku (a jiné analogické aplikace), měl smysl, a jiné, kde by to naopak nešlo. Že má obdélník, jakožto abstraktní geometrický útvar, dvě nezávislé strany, je jedna věc, ale že by objekt obdélník, jakožto prostředek nějakého konkrétního objektového modelu, musel mít bezpodmínečně stejnou vlastnost, to už tedy zdaleka tak zřejmé není. Jestliže někde budu chtít mít obdélníky se zaručenou vlastností, že mají poměr stran 2:1, tak se mi taková definice hodí. Protože budu mít zaručen tento poměr a přitom na takový obdélník mohu aplikovat vše, co platí pro obecný obdélník. Pokud bude obecný obdélník disponovat metodou např. pro nastavení jedné strany na základě zadaného obsahu a druhé strany, tak nastane problém. Ale tohle záleží na konkrétním modelu. Nejde o tom říci nic obecně. Snad jen kromě toho, že kdybych něco takového potřeboval, mělo by to opravdu být součástí toho objektu, ať už obecného obdélníku, nebo nějakého jeho potomka (podle potřeby), ale rozhodně bych to neměl počítat někde mimo, jak tu naznačujete, protože vztahy mezi stranami, obsahem, úhlopříčkami a dalšími vlastnosti obdélníku jsou vnitřními záležitostmi toho objektu.
A ještě jednou zdůrazňuji rozdíl mezi geometrickým pojmem obdélník a obdélníkem jakožto prostředkem objektového modelu, kdyby vás opět napadlo jak zaseklá deska blábolit cosi o porušení kontraktu obdélníku (o němž nic nevíte, protože ho tu nikdo nespecifikoval).

Vypravej mi jeste chvili o praktickych aplikacich...

Tohle je proste skolacka chyba. (Nemluve o tom, ze dalsi skolacka chyba - pokud neni velmi double plus dobry duvod - je designovat to jako mutable. Coz kdyz clovek neudela, tak nemusi resit ani cely tenhle problem.)

A kdybys cetl poradne, tak by sis vsimnul, ze jsem tu psal o tom, ze zalezi na okolnostech davno. A jedna z tech okolnosti je prave ta mutabilita. Jak ji mas, tak proste nedelas takovou hierarchii, jako muze udelat clovek v imutable svete. (Dalsi duvod by mohly byt trebas pametove naroky, ty uz tu take padly.)
Název: Re:Dědičnost dnes
Přispěvatel: ava 23. 01. 2017, 13:54:29
A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Člověče, vy jste si o tom někde něco přečetl, ale totálně vám chybí cit pro praktickou aplikaci. Substituční princip není žádné posvátné tele. Naproti tomu, zákaz provádět mimo objekt něco, co je v kompetenci toho objektu, nebo nepředpokládat o vnitřních vlastnostech toho objektu něco, co není explicitně specifikováno, se tomu svatému teleti blíží mnohem více.
Dovedu si představit spoustu aplikací, kde by čtverec, jakožto potomek obdélníku (a jiné analogické aplikace), měl smysl, a jiné, kde by to naopak nešlo. Že má obdélník, jakožto abstraktní geometrický útvar, dvě nezávislé strany, je jedna věc, ale že by objekt obdélník, jakožto prostředek nějakého konkrétního objektového modelu, musel mít bezpodmínečně stejnou vlastnost, to už tedy zdaleka tak zřejmé není. Jestliže někde budu chtít mít obdélníky se zaručenou vlastností, že mají poměr stran 2:1, tak se mi taková definice hodí. Protože budu mít zaručen tento poměr a přitom na takový obdélník mohu aplikovat vše, co platí pro obecný obdélník. Pokud bude obecný obdélník disponovat metodou např. pro nastavení jedné strany na základě zadaného obsahu a druhé strany, tak nastane problém. Ale tohle záleží na konkrétním modelu. Nejde o tom říci nic obecně. Snad jen kromě toho, že kdybych něco takového potřeboval, mělo by to opravdu být součástí toho objektu, ať už obecného obdélníku, nebo nějakého jeho potomka (podle potřeby), ale rozhodně bych to neměl počítat někde mimo, jak tu naznačujete, protože vztahy mezi stranami, obsahem, úhlopříčkami a dalšími vlastnosti obdélníku jsou vnitřními záležitostmi toho objektu.
A ještě jednou zdůrazňuji rozdíl mezi geometrickým pojmem obdélník a obdélníkem jakožto prostředkem objektového modelu, kdyby vás opět napadlo jak zaseklá deska blábolit cosi o porušení kontraktu obdélníku (o němž nic nevíte, protože ho tu nikdo nespecifikoval).

Vypravej mi jeste chvili o praktickych aplikacich...

Tohle je proste skolacka chyba. (Nemluve o tom, ze dalsi skolacka chyba - pokud neni velmi double plus dobry duvod - je designovat to jako mutable. Coz kdyz clovek neudela, tak nemusi resit ani cely tenhle problem.)

A kdybys cetl poradne, tak by sis vsimnul, ze jsem tu psal o tom, ze zalezi na okolnostech davno. A jedna z tech okolnosti je prave ta mutabilita. Jak ji mas, tak proste nedelas takovou hierarchii, jako muze udelat clovek v imutable svete. (Dalsi duvod by mohly byt trebas pametove naroky, ty uz tu take padly.)

No, tady je problemem spíš než mutabilita to, že nastavovací metody mají obdélník v negativní a getovací metody v pozitivní pozici (v tomto smyslu: https://www.schoolofhaskell.com/user/commercial/content/covariance-contravariance ), do toho samého problému se dostanu když budu mít obdélník sice immutable, ale s copySide metodami:

o = obdelnik(1, 2)
o2 = o.copyWithNewSideA(4)
o2.area == ??

(člověk by čekal že 8, ale kiwi udělal speciální obdélník, který má obě strany jednou stejné a podruhé v poměru zlatého řezu a přijde mu to v pohodě a diví se že se divíme, vždyť obdélník je jen NÁZEV (model), vůbec z toho nevyplývá, že by se měl chovat jako obdélník, který známe (GEOMETRICKÝ KONSTRUKT), a jestli jsme to očekávali, tak jsme hovada co nerozeznají implikaci od ekvivalence a neměli by nás pouštět k počítači).
Název: Re:Dědičnost dnes
Přispěvatel: JS 23. 01. 2017, 14:16:05
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).
Název: Re:Dědičnost dnes
Přispěvatel: ava 23. 01. 2017, 14:24:30
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)
   
Název: Re:Dědičnost dnes
Přispěvatel: čumil 23. 01. 2017, 18:59:58
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)
   
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Název: Re:Dědičnost dnes
Přispěvatel: čumil 23. 01. 2017, 19:00:54
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)
   
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
*transparentnost
Název: Re:Dědičnost dnes
Přispěvatel: Polymath 23. 01. 2017, 19:46:47
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)
   
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.
Název: Re:Dědičnost dnes
Přispěvatel: v 23. 01. 2017, 21:03:23
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.
čumilův příspěvek je i s pravopisnými chybami věcný a k tématu, váš příspěvek je mimo, sprostý a ubohý - a to si myslím i o vás
Název: Re:Dědičnost dnes
Přispěvatel: Cikáda_ 23. 01. 2017, 22:52:05
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)
   
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.

Takové napadání na základě pravopisu je ubohé a o něčem vypovídá. Zvlášť když příspěvek byl věcný a smysluplný, byť s chybami (znám několik velmi velmi inteligentních lidí, kteří nepíší korektně, ale nemohou za to).
Název: Re:Dědičnost dnes
Přispěvatel: pr 24. 01. 2017, 06:01:00
No já nevím... Erlang je dostatečně funkcionální (jasně, není pure..) a IMHO dostatečně OOP...
Název: Re:Dědičnost dnes
Přispěvatel: JS 24. 01. 2017, 07:09:31
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...

S tim nesouhlasim. Ano, v jistem smyslu jsou dualni - kazdy OOP program/pattern lze 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.

Ale FP ma v tomhle mirnou vyhodu, protoze predavani funkci identity je v programu mnohem lepe videt nez predavani identickych dat. Takze v OOP pristupu snadno vzniknou mezivrstvy, ktere by v FP bylo mozne trivialne odstranit.

Druha, taky znacna vyhoda FP, plyne z toho, ze je postavene na matematicke teorii (a nikoli tolik na intuici navrharu jazyka) a tudiz je o neco rigoroznejsi. Take to vede k tomu, ze nektere koncepty, ktere existuji treba v Jave jako duplicitni (napr. navratova hodnota a vyjimka) je mozne v FP modelovat jako stejnou/podobnou vec.

Oba problemy by sly asi odstranit, ale muselo by se OOP koncipovat trochu jinak (coz ale asi nema smysl z historickych duvodu). Jak uz to tak byva, vyvoj temer vzdy probiha od slozitejsiho k jednodussimu.

Konecne, je take mozne, ze FP vede k lepsi znovupouzitelnosti. V FP jsou to datove typy, ktere tvori API mezi jednotlivymi funkcemi, narozdil od interfacu v OOP. Vyhoda je v tom, ze datove typy jsou samopopisne (protoze nemaji chovani), zatimco interface je napul definovany chovanim prislusne implementace (ono vubec interface toho moc o chovani objektu nerika). Je to podobne jako v Unixu - prikazy Unixu maji take sva vstupni/vystupni data (typicky samopopisny text) jako API, a proto jsou velmi znovupouzitelne.
Název: Re:Dědičnost dnes
Přispěvatel: Inkvizitor 24. 01. 2017, 08:25:53
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.
čumilův příspěvek je i s pravopisnými chybami věcný a k tématu, váš příspěvek je mimo, sprostý a ubohý - a to si myslím i o vás

Čumilovy příspěvky jsou často nejenom sprosté (včetně Tebou citovaného), ale i pitomé (včetně Tebou citovaného). Jeho pravopis už je jenom taková třešnička na dortu. A Ty asi neumíš číst, když obhajuješ někoho takového (i se zmíněným citátem).
Název: Re:Dědičnost dnes
Přispěvatel: Cikáda_ 24. 01. 2017, 09:20:37
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.
čumilův příspěvek je i s pravopisnými chybami věcný a k tématu, váš příspěvek je mimo, sprostý a ubohý - a to si myslím i o vás

Čumilovy příspěvky jsou často nejenom sprosté (včetně Tebou citovaného), ale i pitomé (včetně Tebou citovaného). Jeho pravopis už je jenom taková třešnička na dortu. A Ty asi neumíš číst, když obhajuješ někoho takového (i se zmíněným citátem).

A nebylo by lepší se zbavit těch předsudků? Podle pravopisných chyb měřit IQ? (také mne to bije do očí, ale dělat takovéto závěry?!) Kvůli tomu, že někdo souhlasí s někým, kdo občas napíše nějaké slovo s chybou, mu říkat, že neumí číst? Ale prosím vás... to je vážně ubohé. :)
Název: Re:Dědičnost dnes
Přispěvatel: ava 24. 01. 2017, 09:31:45
Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM (https://www.youtube.com/watch?v=QM1iUe6IofM).)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)
   
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...

I kdybych se držel Kayovi definice, není proti tomu co píšu. Nezapomínej, že zprávy ve smalltalku jsou synchronní, tj. vrací hodnoty, poslání zprávy neznamená že je spolknutá, ale s jejím výsledkem můžeš dál pracovat. Nepřipomíná ti to něco? Jo, funkce :) Tj. klidně je možné mít celý Smalltalk immutable, referenčně transparentní, a jen někde na okraji světa mít pár side-effectujících metod pro komunikaci s periferiemi.

na map a foldu atp. FP nestojí, to je pravda, ale tak bez slušné FP knihovny člověk jaksi není moc motivovaný v FP stylu psát..

Co se týče toho, jestli je FP lepší než OOP, jasně, to je subjektivní, ale (mutable) OOP se začíná dostávat do problémů s tím, jak se rozšiřuje nutnost paralelizovat (takt CPU moc nestoupá, ale  počet jo), mutabilita by default nutně vede k race conditions, pak se musí řešit hluboké kopie, zámky, .... Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...
Název: Re:Dědičnost dnes
Přispěvatel: ava 24. 01. 2017, 09:37:40
Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Jen bokem, já teda aktory moc rád nemám, jsou to stavové A asynchronní potvory , takže se (aspoň mě) dost blbě uvažuje nad chováním takového aktorového systému (horší než OOP :) ) - ale moc zkušeností s nimi nemám. FRP se mi líbí víc.
Název: Re:Dědičnost dnes
Přispěvatel: noef 24. 01. 2017, 09:59:56
Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Jen bokem, já teda aktory moc rád nemám, jsou to stavové A asynchronní potvory , takže se (aspoň mě) dost blbě uvažuje nad chováním takového aktorového systému (horší než OOP :) ) - ale moc zkušeností s nimi nemám. FRP se mi líbí víc.

Nejsou totiz aktori "silnejsi"? Nemam s tim zkusenosti, ale Akka streamy jsou narozdil od aktoru typovane a co jsem cetl, tak by melo zalezet na konkretnim problemu - to, ze aktori stoji vyse z pohledu abstrakce neznamena, ze se hodi na vse.

S tim Smalltalkem a Akka actory jsem spis mel na mysli pozdni vazbu. Nikdy nevite, jakeho typu (ve vyznamu typoveho systemu Scaly) je aktor na druhe strane - proste je to vzdy instance nejake jedne tridy. A i kdyby typ bylo povoleno pouzivat (myslim, ze technicky to lze, ale obchazi se tim aktor model), tak to neni moc uzitecne, protoze aktori muzou menit za behu na ktere zpravy reaguji - coz IMO odpovida tomu, kdyby se za behu pridavaly/odebiraly metody, napr. jako v JavaScriptu (coz nad JVM nebude trivialni jako v JS, navic tim ztratite vsechny vyhody statickeho jazyka jako treba podporu IDE, protoze z toho jazyka vlastne delate dynamicky).
Název: Re:Dědičnost dnes
Přispěvatel: ava 24. 01. 2017, 10:16:58
Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Jen bokem, já teda aktory moc rád nemám, jsou to stavové A asynchronní potvory , takže se (aspoň mě) dost blbě uvažuje nad chováním takového aktorového systému (horší než OOP :) ) - ale moc zkušeností s nimi nemám. FRP se mi líbí víc.

Nejsou totiz aktori "silnejsi"? Nemam s tim zkusenosti, ale Akka streamy jsou narozdil od aktoru typovane a co jsem cetl, tak by melo zalezet na konkretnim problemu - to, ze aktori stoji vyse z pohledu abstrakce neznamena, ze se hodi na vse.

S tim Smalltalkem a Akka actory jsem spis mel na mysli pozdni vazbu. Nikdy nevite, jakeho typu (ve vyznamu typoveho systemu Scaly) je aktor na druhe strane - proste je to vzdy instance nejake jedne tridy. A i kdyby typ bylo povoleno pouzivat (myslim, ze technicky to lze, ale obchazi se tim aktor model), tak to neni moc uzitecne, protoze aktori muzou menit za behu na ktere zpravy reaguji - coz IMO odpovida tomu, kdyby se za behu pridavaly/odebiraly metody, napr. jako v JavaScriptu (coz nad JVM nebude trivialni jako v JS, navic tim ztratite vsechny vyhody statickeho jazyka jako treba podporu IDE, protoze z toho jazyka vlastne delate dynamicky).

Ano, v tomhle smyslu jsou Aktoři silnější - a to se mi právě na nich nelíbí, ten typ Any => Unit, je to takový blackbox bez typu.

Slabší (s více omezeními) na jedné úrovni může znamenat silnější (vyšší kontrola nad nižší úrovní, více možností jak se stavebními prvky nižší úrovně nakládat) na vyšší úrovni. O tomhle tématu se mi líbí přednáška

https://www.youtube.com/watch?v=GqmsQeSzMdw

Akka zřejmě umí nějak i typované aktory (http://doc.akka.io/docs/akka/current/scala/typed-actors.html), ale nikdy jsem se s tím osobně nepotkal.
Název: Re:Dědičnost dnes
Přispěvatel: noef 24. 01. 2017, 10:23:14
Ti typovani Aktori jsou stale experimentalni, ale nevypada to marne. http://doc.akka.io/docs/akka/current/scala/typed.html#typed-scala
Název: Re:Dědičnost dnes
Přispěvatel: Polymath 24. 01. 2017, 10:24:07
Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.
čumilův příspěvek je i s pravopisnými chybami věcný a k tématu, váš příspěvek je mimo, sprostý a ubohý - a to si myslím i o vás

Čumilovy příspěvky jsou často nejenom sprosté (včetně Tebou citovaného), ale i pitomé (včetně Tebou citovaného). Jeho pravopis už je jenom taková třešnička na dortu. A Ty asi neumíš číst, když obhajuješ někoho takového (i se zmíněným citátem).

A nebylo by lepší se zbavit těch předsudků? Podle pravopisných chyb měřit IQ?

Kdo neumí správně ani pravopis, těžko může rozumět mnohem složitějším věcem jako programování. Zrovna čumil navíc většinou sprostě uráží. Je to zakomplexovaný, nepříliš inteligentní ubožák. Obhajovat ho taky o něčem svědčí, ale to už je každého problém.
Název: Re:Dědičnost dnes
Přispěvatel: bob 24. 01. 2017, 11:19:10
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 ;) ).

Tady se ale člověk doví sraček :D
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

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...
Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.
čumilův příspěvek je i s pravopisnými chybami věcný a k tématu, váš příspěvek je mimo, sprostý a ubohý - a to si myslím i o vás

Čumilovy příspěvky jsou často nejenom sprosté (včetně Tebou citovaného), ale i pitomé (včetně Tebou citovaného). Jeho pravopis už je jenom taková třešnička na dortu. A Ty asi neumíš číst, když obhajuješ někoho takového (i se zmíněným citátem).

A nebylo by lepší se zbavit těch předsudků? Podle pravopisných chyb měřit IQ?

Kdo neumí správně ani pravopis, těžko může rozumět mnohem složitějším věcem jako programování. Zrovna čumil navíc většinou sprostě uráží. Je to zakomplexovaný, nepříliš inteligentní ubožák. Obhajovat ho taky o něčem svědčí, ale to už je každého problém.

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.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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í.
Název: Re:Dědičnost dnes
Přispěvatel: SB 24. 01. 2017, 12:43:23
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ů.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: SB 24. 01. 2017, 13:09:51

I kdybych se držel Kayovi definice, není proti tomu co píšu. Nezapomínej, že zprávy ve smalltalku jsou synchronní, tj. vrací hodnoty, poslání zprávy neznamená že je spolknutá, ale s jejím výsledkem můžeš dál pracovat. Nepřipomíná ti to něco? Jo, funkce :) Tj. klidně je možné mít celý Smalltalk immutable, referenčně transparentní, a jen někde na okraji světa mít pár side-effectujících metod pro komunikaci s periferiemi.

...

Co se týče toho, jestli je FP lepší než OOP, jasně, to je subjektivní, ale (mutable) OOP se začíná dostávat do problémů s tím, jak se rozšiřuje nutnost paralelizovat (takt CPU moc nestoupá, ale  počet jo), mutabilita by default nutně vede k race conditions, pak se musí řešit hluboké kopie, zámky, .... Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Zprávy mají s funkcemi společnou jedinou věc, a to, že synchronně vracejí odpověď. Tím jejich podobnost končí. Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Aktorový model je samozřejmě taky mutable, je asynchronní obdobou objektů, tj. zachovává identitu. Jeho simulace v OOP je triviální (jestli mi něco neušlo) - objekt přijímá zprávy (obsahující nějakou formu callbacku) asynchronně (tj. odpověď je třeba pouze dobrý/špatný) a štosuje si je do fronty, kterou postupně zpracovává.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 24. 01. 2017, 13:13:40

I kdybych se držel Kayovi definice, není proti tomu co píšu. Nezapomínej, že zprávy ve smalltalku jsou synchronní, tj. vrací hodnoty, poslání zprávy neznamená že je spolknutá, ale s jejím výsledkem můžeš dál pracovat. Nepřipomíná ti to něco? Jo, funkce :) Tj. klidně je možné mít celý Smalltalk immutable, referenčně transparentní, a jen někde na okraji světa mít pár side-effectujících metod pro komunikaci s periferiemi.

...

Co se týče toho, jestli je FP lepší než OOP, jasně, to je subjektivní, ale (mutable) OOP se začíná dostávat do problémů s tím, jak se rozšiřuje nutnost paralelizovat (takt CPU moc nestoupá, ale  počet jo), mutabilita by default nutně vede k race conditions, pak se musí řešit hluboké kopie, zámky, .... Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Zprávy mají s funkcemi společnou jedinou věc, a to, že synchronně vracejí odpověď. Tím jejich podobnost končí. Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Zalezi, co chces. Jedna moznost je trebas nejaka podoba event-sourcingu, kde je mutabilita omezena prakticky na jediny bod.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 24. 01. 2017, 13:17:48
Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.
Monády.
Název: Re:Dědičnost dnes
Přispěvatel: SB 24. 01. 2017, 13:25:12
...
S tim Smalltalkem a Akka actory jsem spis mel na mysli pozdni vazbu. Nikdy nevite, jakeho typu (ve vyznamu typoveho systemu Scaly) je aktor na druhe strane - proste je to vzdy instance nejake jedne tridy. A i kdyby typ bylo povoleno pouzivat (myslim, ze technicky to lze, ale obchazi se tim aktor model), tak to neni moc uzitecne, protoze aktori muzou menit za behu na ktere zpravy reaguji - coz IMO odpovida tomu, kdyby se za behu pridavaly/odebiraly metody, napr. jako v JavaScriptu (coz nad JVM nebude trivialni jako v JS, navic tim ztratite vsechny vyhody statickeho jazyka jako treba podporu IDE, protoze z toho jazyka vlastne delate dynamicky).

Nějak nevidím překážku v typovaných aktorech a jejich receptorech, poslat zprávu jde i typovaně. Ale nechám se poučit.
Reakce na zprávy se dá nasimulovat i jinak než přidáváním a odebíráním metod.
Název: Re:Dědičnost dnes
Přispěvatel: bob 24. 01. 2017, 13:29:55
Aktorový model je samozřejmě taky mutable, je asynchronní obdobou objektů, tj. zachovává identitu. Jeho simulace v OOP je triviální (jestli mi něco neušlo) - objekt přijímá zprávy (obsahující nějakou formu callbacku) asynchronně (tj. odpověď je třeba pouze dobrý/špatný) a štosuje si je do fronty, kterou postupně zpracovává.

On je mutable v ramci objektu, ktery je ale zvenci black box. Ono zapouzdreni neni, ze se vsechny promenne udelaji private a napisi k tomu gettery a settery. Zapouzdreni znamena, ze nevidis z venci, jak to uvnitr funguje a neleakuje ven implementace. Takze pokud to je vhodne tam klidne je public promenna a at si s tim kazdy dela co chce.

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Název: Re:Dědičnost dnes
Přispěvatel: bob 24. 01. 2017, 13:30:58

Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.

Název: Re:Dědičnost dnes
Přispěvatel: JS 24. 01. 2017, 13:33:08
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á.

Myslel jsem to tak, ze v OOP se data vybaluji v metodach toho objektu, v tom smyslu je to "delegovani". S delegaty to nema nic spolecneho.

Citace
Zbytek příspěvku, co je a není FP, považuju za deklarativní konstrukce či dojmy bez důkazů či příkladů.

Zkus si to precist znovu a zamyslet se nad tim.. Muzu nektere veci dovysvetlit.

Je to trochu podobne zmene vztazne soustavy. Zatimco v OOP systemem prochazeji data, v FP systemem prochazeji funkce. Proto je take FP tak uzitecne v distribuovanych systemech typu Hadoop, Spark apod., protoze ty jsou zalozene na zasilani operaci nad daty a nikoli dat (lze-li se tomu vyhnout).
Název: Re:Dědičnost dnes
Přispěvatel: zboj 24. 01. 2017, 13:34:31

Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.
Název: Re:Dědičnost dnes
Přispěvatel: SB 24. 01. 2017, 13:34:51
...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).
...

Jako tvrzení je to pochopitelně úplný nesmysl, odkaz (skládání) neznamená, že je něco uvnitř, to je taková naivní představa ještě pocházející z procedurálního programování s primitivními, nereferenčními typy. Zadruhé skutečnost, že objekt vidí kámoše, ještě neznamená, že vidí i kámoše kámoše, naopak je to vyloženě nechtěný stav porušující zapouzdření.
Zbytek příspěvku o propagaci změny modelovanou doménou je nesrozumitelný.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 13:40:09
jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.
Název: Re:Dědičnost dnes
Přispěvatel: bob 24. 01. 2017, 14:08:14
jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.

Ja psal jak to bylo puvodne navrzeny a nekomu se taky zdalo, ze je to komplikovany a vznikla... Java
Název: Re:Dědičnost dnes
Přispěvatel: zboj 24. 01. 2017, 14:08:54
jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.
ObjC je dynamické a použitelné ;)
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 14:46:23
jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.

Ja psal jak to bylo puvodne navrzeny a nekomu se taky zdalo, ze je to komplikovany a vznikla... Java

Tak to je super a máme z toho nejpopulárnější jazyk. Tak si to představuju.

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.
ObjC je dynamické a použitelné ;)

A kde se dnes používá? Jen abych měl představu, jestli je čas se na něj dívat :)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 24. 01. 2017, 14:58:45
A kde se dnes používá? Jen abych měl představu, jestli je čas se na něj dívat :)
Na všem od Applu, přičemž Apple zatím nepoužívá Swift, protože nemá stabilní ABI.
Název: Re:Dědičnost dnes
Přispěvatel: bob 24. 01. 2017, 15:11:03

Tak to je super a máme z toho nejpopulárnější jazyk. Tak si to představuju.


Takovej Justin Bieber je taky nejpopularnejsi...
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 15:12:48
A kde se dnes používá? Jen abych měl představu, jestli je čas se na něj dívat :)
Na všem od Applu, přičemž Apple zatím nepoužívá Swift, protože nemá stabilní ABI.

Ahaaa, tak to mi asi moc nepomůže. Orientuju se spíše na backendy. Velké backendy na serverech. Ale Swift také nevypadá špatně. Jsem myslel, že iPhone to používá pro aplikace.

Tak to je super a máme z toho nejpopulárnější jazyk. Tak si to představuju.
Takovej Justin Bieber je taky nejpopularnejsi...

A chceš říct, že je snad špatný?
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 15:14:34
A kde se dnes používá? Jen abych měl představu, jestli je čas se na něj dívat :)
Na všem od Applu, přičemž Apple zatím nepoužívá Swift, protože nemá stabilní ABI.

To nemusí o použitelnosti jazyka vypovídat nic. Korporace typu Apple nebo Google dokáží protlačit cokoliv. Vy jim tu děláte dobré PR.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 24. 01. 2017, 15:36:11
A kde se dnes používá? Jen abych měl představu, jestli je čas se na něj dívat :)
Na všem od Applu, přičemž Apple zatím nepoužívá Swift, protože nemá stabilní ABI.

Ahaaa, tak to mi asi moc nepomůže. Orientuju se spíše na backendy. Velké backendy na serverech. Ale Swift také nevypadá špatně. Jsem myslel, že iPhone to používá pro aplikace.

Apple ho na iOS prosazuje, ale sám stále čeká na stabilní ABI, Xcode teď přikládá standardní knihovnu ke každé aplikaci, takže typicky aplikace má pod 1MB a k ní si každý uživatel stahuje něco kolem 20MB knihoven, přitom u každé aplikace v podstatě to samé (liší se jen verzí Swiftu použitou při vývoji). Až bude stabilní ABI, budou swiftí knihovny součástí OS a aplikace k nim bude dynamicky linkovat bez nutnosti nést si je s sebou.

Swift má nejsilnější a nejelegantnější syntax, ale implementace pokulhává.

Jinak nějaké frameworky pro backend ve Swiftu existují, ale já to zatím ignoruju, překladač i standardní knihovna mají spoustu bugů, mnohem lepší je v tomto ohledu Go, resp. cokoliv z mainstreamu včetně snad i Prologu :)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 24. 01. 2017, 15:40:25
A kde se dnes používá? Jen abych měl představu, jestli je čas se na něj dívat :)
Na všem od Applu, přičemž Apple zatím nepoužívá Swift, protože nemá stabilní ABI.

To nemusí o použitelnosti jazyka vypovídat nic. Korporace typu Apple nebo Google dokáží protlačit cokoliv. Vy jim tu děláte dobré PR.
To byla odpověď na otázku, kde se používá ObjC. PR dělat nechci a osobně bych ObjC už ani nedoporučoval, přece jen je přes všechny své výhody překonané (byť někteří exoti jako Čada na něm stále slepě lpí, ale to nechme psychiatrům).
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 24. 01. 2017, 16:11:06
(člověk by čekal že 8, ale kiwi udělal speciální obdélník, který má obě strany jednou stejné a podruhé v poměru zlatého řezu a přijde mu to v pohodě a diví se že se divíme, vždyť obdélník je jen NÁZEV (model), vůbec z toho nevyplývá, že by se měl chovat jako obdélník, který známe (GEOMETRICKÝ KONSTRUKT), a jestli jsme to očekávali, tak jsme hovada co nerozeznají implikaci od ekvivalence a neměli by nás pouštět k počítači).

Nepochopení rozdílu mezi objektem reálného světa či objektem abstraktního světa na jedné straně a objektem jakožto základní entitou objektového modelu pro účely implementace počítačového programu na straně druhé je velice častým zdrojem chyb při návrhu. Snažíte se násilím za každou cenu co nejvěrněji rekonstruovat vlastnosti nějakého reálného (či naopak abstraktního) vzoru, včetně klasifikační hierarchie, bez ohledu na to, je-li to k něčemu dobré.
K čemu je mi dobré, že speciální obdélník nemůže mít za žádnou cenu z nějakého obskurního důvodu, jehož praktický význam vlastně ani jeho proponent nedokáže uspokojivě obhájit pro univerzální případ, nikdy žádnou pevnou vazbu mezi stranami, když by se mi to v nějaké konkrétní aplikaci hodilo?
Uvědomte si, že přístupy jako strukturované, funkcionální, objektové aj. programování vznikala kvůli tomu, aby zjednodušila návrh programu. Pokud kvůli nějakým principům, vytrženým z kontextu, vhodným pro problém A, ale naprosto nevhodným pro problém B, musím psát program 3x tak dlouhý a nepřehledný, tak je něco špatně.

To byla odpověď na otázku, kde se používá ObjC. PR dělat nechci a osobně bych ObjC už ani nedoporučoval, přece jen je přes všechny své výhody překonané (byť někteří exoti jako Čada na něm stále slepě lpí, ale to nechme psychiatrům).

Dynamické a použitelné jsou i např. Ruby nebo Python.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 16:33:18

Dynamické a použitelné jsou i např. Ruby nebo Python.

Právě ani jeden není. Python je na malé skriptíky a Ruby také. Oba se dají dost dobře použít na webíky, ale to je tak všechno. Přesně ta jejich dynamičnost je vyřazuje z použití. Také metatřídy v Pythonu to všechno jen dodělají :D Jako nic proti nim, jen to je přesně ten příklad jazyků, které použít na větší věci nejde. Proto se tam ani nepoužívají. Kdyby ta dynamičnost byla tak úžasná, tak to nepoužívají hlavně admini, kteří vyvíjet neumí.
Název: Re:Dědičnost dnes
Přispěvatel: bob 24. 01. 2017, 17:00:01
Jako tvrzení je to pochopitelně úplný nesmysl, odkaz (skládání) neznamená, že je něco uvnitř, to je taková naivní představa ještě pocházející z procedurálního programování s primitivními, nereferenčními typy. Zadruhé skutečnost, že objekt vidí kámoše, ještě neznamená, že vidí i kámoše kámoše, naopak je to vyloženě nechtěný stav porušující zapouzdření.
Zbytek příspěvku o propagaci změny modelovanou doménou je nesrozumitelný.

Ale ano znamena. Objekt A ma svuj stav a referenci na B. B ma svuj stav. B zmeni svuj stav. Chovani A se zmenilo i kdyz volas stejnou metodu se stejnymi parametry,vraci neco jineho. A protoze to ma byt z venku black box, pak nutne A zmenilo svuj stav.

A takhle to muze byt, a taky byva pres vsechny tridy v cele aplikaci.

To je tak krasa Java style OOP.

Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 24. 01. 2017, 17:01:25

Dynamické a použitelné jsou i např. Ruby nebo Python.

Právě ani jeden není. Python je na malé skriptíky a Ruby také. Oba se dají dost dobře použít na webíky, ale to je tak všechno. Přesně ta jejich dynamičnost je vyřazuje z použití. Také metatřídy v Pythonu to všechno jen dodělají :D Jako nic proti nim, jen to je přesně ten příklad jazyků, které použít na větší věci nejde. Proto se tam ani nepoužívají. Kdyby ta dynamičnost byla tak úžasná, tak to nepoužívají hlavně admini, kteří vyvíjet neumí.

V Pythonu je např. napsáno toto: http://frescobaldi.org
Neřekl bych, že jde zrovna o nějaký malý skriptík. U nás v tom máme napsaný poměrně rozsáhlý framework pro testování a validace. Našlo by se toho jistě mnohem víc.
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 17:07:47

Dynamické a použitelné jsou i např. Ruby nebo Python.

Právě ani jeden není. Python je na malé skriptíky a Ruby také. Oba se dají dost dobře použít na webíky, ale to je tak všechno. Přesně ta jejich dynamičnost je vyřazuje z použití. Také metatřídy v Pythonu to všechno jen dodělají :D Jako nic proti nim, jen to je přesně ten příklad jazyků, které použít na větší věci nejde. Proto se tam ani nepoužívají. Kdyby ta dynamičnost byla tak úžasná, tak to nepoužívají hlavně admini, kteří vyvíjet neumí.

Můžete uvést nějaký konkrétní příklad, kdy vám metatřídy komplikovaly práci? Programátoři aplikací to nepoužívají a těch několik knihoven, co je používá to má odladěné.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 17:27:58

Dynamické a použitelné jsou i např. Ruby nebo Python.

Právě ani jeden není. Python je na malé skriptíky a Ruby také. Oba se dají dost dobře použít na webíky, ale to je tak všechno. Přesně ta jejich dynamičnost je vyřazuje z použití. Také metatřídy v Pythonu to všechno jen dodělají :D Jako nic proti nim, jen to je přesně ten příklad jazyků, které použít na větší věci nejde. Proto se tam ani nepoužívají. Kdyby ta dynamičnost byla tak úžasná, tak to nepoužívají hlavně admini, kteří vyvíjet neumí.

Můžete uvést nějaký konkrétní příklad, kdy vám metatřídy komplikovaly práci? Programátoři aplikací to nepoužívají a těch několik knihoven, co je používá to má odladěné.

Za prvé můžeš mít neschopné kolegy, kteří je nacpou všude. A za druhé jsou projekty, které je asi tak odladěné něměly. Třeba Django a jejich ORM je super využití. Jenže tam nikdo mít problém snad ani nemůže. Bohužel je lepší mít asi jazyk více osekaný a dělat to jinak. ORM v Javě také máš a tam žádné metatřídy nejsou. Takže se to jeví cool asi jako ta dynamičnost. Není to obecně dobrý nápad mít v jazyce.

A třeba OOP v Pythonu, které bylo ve 2 spíše jako vtip a ve trojce je pořád nic moc, ale lepší než nic. Takže pokud mi někdo řekne, že se  tenhle jazyk na něco velkého hodí, tak to dost vypovídá o jeho schopnostech.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 24. 01. 2017, 17:51:24
Takže pokud mi někdo řekne, že se  tenhle jazyk na něco velkého hodí, tak to dost vypovídá o jeho schopnostech.

Spíš o tvých neschopnostech.  ;)
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 18:12:31

Dynamické a použitelné jsou i např. Ruby nebo Python.

Právě ani jeden není. Python je na malé skriptíky a Ruby také. Oba se dají dost dobře použít na webíky, ale to je tak všechno. Přesně ta jejich dynamičnost je vyřazuje z použití. Také metatřídy v Pythonu to všechno jen dodělají :D Jako nic proti nim, jen to je přesně ten příklad jazyků, které použít na větší věci nejde. Proto se tam ani nepoužívají. Kdyby ta dynamičnost byla tak úžasná, tak to nepoužívají hlavně admini, kteří vyvíjet neumí.

Můžete uvést nějaký konkrétní příklad, kdy vám metatřídy komplikovaly práci? Programátoři aplikací to nepoužívají a těch několik knihoven, co je používá to má odladěné.

Za prvé můžeš mít neschopné kolegy, kteří je nacpou všude. A za druhé jsou projekty, které je asi tak odladěné něměly. Třeba Django a jejich ORM je super využití. Jenže tam nikdo mít problém snad ani nemůže. Bohužel je lepší mít asi jazyk více osekaný a dělat to jinak. ORM v Javě také máš a tam žádné metatřídy nejsou. Takže se to jeví cool asi jako ta dynamičnost. Není to obecně dobrý nápad mít v jazyce.

A třeba OOP v Pythonu, které bylo ve 2 spíše jako vtip a ve trojce je pořád nic moc, ale lepší než nic. Takže pokud mi někdo řekne, že se  tenhle jazyk na něco velkého hodí, tak to dost vypovídá o jeho schopnostech.

Využití metatříd je hlavně v programátorských nástrojích a podobně. Stačí jejich použití v projektu zakázat. Stejného efektu jako metatřídou lze většinou dosáhnout i dekorátorem třídy mnohem explicitněji.

ani guru David Beazley si není jistý, kdy je vhodné použít metaclassu:

https://www.youtube.com/watch?v=sPiWg5jSoZI

Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 18:44:35
A třeba OOP v Pythonu, které bylo ve 2 spíše jako vtip a ve trojce je pořád nic moc, ale lepší než nic. Takže pokud mi někdo řekne, že se  tenhle jazyk na něco velkého hodí, tak to dost vypovídá o jeho schopnostech.

V čem se zásadně liší OOP v pythonu 3 oproti 2?
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 19:10:41
A třeba OOP v Pythonu, které bylo ve 2 spíše jako vtip a ve trojce je pořád nic moc, ale lepší než nic. Takže pokud mi někdo řekne, že se  tenhle jazyk na něco velkého hodí, tak to dost vypovídá o jeho schopnostech.

V čem se zásadně liší OOP v pythonu 3 oproti 2?

Nevím, to mi říkali lidi, kteří měli rádi Python. Ve dvojce to byla jen taková parodie na OOP. Ve trojce by to mělo být lepší. Nebo pokud je to stejně špatné jako u dvojky, tak to asi není moc co řešit.
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 19:27:13
Nevím, to mi říkali lidi, kteří měli rádi Python. Ve dvojce to byla jen taková parodie na OOP. Ve trojce by to mělo být lepší. Nebo pokud je to stejně špatné jako u dvojky, tak to asi není moc co řešit.

Parodie podle člověka, který to nikdy nepoužil. Další programátor teoretik.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 19:46:03
Kde to má rozhraní? Kde je nějaké zapouzdření, když je vše public? Kde je nějaká dědičnost, když všechno je dynamické a nikdo mi nebrání cokoli přepsat? Tomu fakt říkáš jazyk na vývoj?
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 24. 01. 2017, 19:55:37
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ů.
Obecná tvrzení nejsou vetšinou pravdivá :)

Záleží na tom, jak by se FP a OOP vlastně měly kobinovat a především taky na definici, co je FP a co je OOP. Chceš-li konkrétní příklad, nastuduj si, jak (na nejvyšší úrovni) funguje Erlang: aplikace se skládá z procesů, procesy mezi sebou komunikují výhradně zasíláním asynchronních zpráv (až na drobné výjimky jako třeba sdílená databáze, ale to se používá málo), nemůžou mít žádný sdílený stav a vnitřní fungování procesů je naprogramováno funkcionálně (spíš pragmatická než čistá implementace FP - jsou např. možné vedlejší efekty). => procesy jsou aktory => procesy se velmi podobají objektům ve Smalltalku => je tam "OOP" (nikdo se tím moc nechlubí, aby se toho nechytali Javisti apod., ale je to tak) i FP.
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 20:07:35
Kde to má rozhraní? Kde je nějaké zapouzdření, když je vše public? Kde je nějaká dědičnost, když všechno je dynamické a nikdo mi nebrání cokoli přepsat? Tomu fakt říkáš jazyk na vývoj?

proč sis javamane změnil jméno? Používej si co chceš, ale nepiš o věcech, které neznáš.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 24. 01. 2017, 20:26:09
Zprávy mají s funkcemi společnou jedinou věc, a to, že synchronně vracejí odpověď. Tím jejich podobnost končí.
To je minimálně zavádějící tvrzení.

1. funkce jsou statické, zprávy jsou akce

Pokud se "funkcí" myslí to, co funkce znamená v (čistém) FP, tak funkce není nic jiného než zkratka pro nějaký dlouhý výraz - kdekoliv dám funkci, tam bych mohl dát ten dlouhý výraz (referenční transparentnost), nic víc. Celý program v čistém FP je vlastně striktně vzato sémanticky úplně statický - není to popis činnosti (co se má udělat kdy a jak), je to úplně statický popis relací mezi daty. Např. fce sqr(x) neříká "vem x a udělej s ním něco", říká, že čísla 3 a 9 jsou v relaci sqr. Protože samozřejmě chceme programovat nějakou činnost, má FP jazyk nějaký runtime, který tu statickou strukturu vezme a podle ní něco dělá. V samotném jazyce ale nic "dělat" nejde. Není jak.

2. zprávy nemusí být synchronní

...a dokonce je lepší, když defaultně nejsou, protože sesynchronizovat asynchronní události je v dobře navrženém jazyce triviální (kód v jazyce Elixir):
Kód: [Vybrat]
# synchronni fce - vrati :ok nebo :timeout
def ping_sync do
  # poslu zpravu agentovi
  send(agent,{self(),:ping})
  # cekam na odpoved nebo timeout
  receive do
    :pong -> :ok
  after 5000 -> :timeout
  end
end

3. odeslání zprávy nemusí nic "vracet" nebo může "vracet" víc hodnot postupně

Např. můžu actoru poslat zprávu
Kód: [Vybrat]
{self(),:subscribe_seconds}
a on mi od té doby bude každou sekundu posílat zprávy typu
Kód: [Vybrat]
{:seconds_now,1485285333}
Zprávy pochopitelně chodí úplně nezávisle na tom, co zrovna příjemce dělá (tj. musí tam být nějaký mailbox). A je čistě na příjemci, jestli je zahodí, nebo si hodnotu aktuálního času napíše na čelo lihovou fixkou :)

...prostě asynchronní zprávy kombinované se vzájemně neblokovanými aktory/agenty mají obrovské možnosti, které se dost těžko představují, dokud si v tom člověk fakt prakticky nezkusí něco napsat.

Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.
Immutable je immutable, takže pokud si pod "změnou stavu" představuješ změnu in situ, tak nijak. Jinak to ale může vypadat třeba takhle (jeden příklad z jiného světa, když odpověď "monády" ti nestačila):

Kód: [Vybrat]
# zjednodušený ilustrační příklad, v reálu by to vypadalo trochu jinak
defmodule StateHolder do
  # tahle funkce spustí agenta držícího stav
  def start_link() do
    # spustí funkci loop s parametry [0] v novém vlákně
    spawn_link(fn -> loop(0) end)
  end

  def loop(state) do
    receive do
      {:add,k} ->
        new_state = state + k
        IO.puts "stav se meni z #{state} na #{new_state}"
        loop(new_state)
      {:get_state,pid} ->
        send(pid,{:state_is,state})
        loop(state)
    end
  end

end
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 24. 01. 2017, 20:37:09
K tomu StateHolder ještě praktická ukázka použití, pokud to někomu pomůže...

Kód: [Vybrat]
iex(2)> sh = StateHolder.start_link
#PID<0.107.0>

iex(3)> send(sh,{:get_state,self()})
{:get_state, #PID<0.81.0>}        <--------- funkce send/2 vrací to, co poslala, to nás nezajímá

iex(4)> flush           <----------- tímhle vyberu zprávy pro aktuální proces (tj. "tazatele", ne sh)
{:state_is, 0}
:ok

iex(5)> send(sh,{:add,10})
stav se meni z 0 na 10      <----------- tohle vypsal StateHolder
{:add, 10}

iex(6)> send(sh,{:add,10})
stav se meni z 10 na 20
{:add, 10}

iex(7)> send(sh,{:get_state,self()})
{:get_state, #PID<0.81.0>}

iex(8)> flush
{:state_is, 20}
:ok
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 20:47:28
Kde to má rozhraní? Kde je nějaké zapouzdření, když je vše public? Kde je nějaká dědičnost, když všechno je dynamické a nikdo mi nebrání cokoli přepsat? Tomu fakt říkáš jazyk na vývoj?

proč sis javamane změnil jméno? Používej si co chceš, ale nepiš o věcech, které neznáš.

Co z toho není pravda? Proč se asi moc nerozšířil na pořádný vývoj?
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 21:13:37
Kde to má rozhraní? Kde je nějaké zapouzdření, když je vše public? Kde je nějaká dědičnost, když všechno je dynamické a nikdo mi nebrání cokoli přepsat? Tomu fakt říkáš jazyk na vývoj?

proč sis javamane změnil jméno? Používej si co chceš, ale nepiš o věcech, které neznáš.

Co z toho není pravda? Proč se asi moc nerozšířil na pořádný vývoj?

vše je pravda. Nechci se hádat, který jazyk je lepší. Původně jsem reagoval na tvé tvrzení o metaclasách.
Název: Re:Dědičnost dnes
Přispěvatel: phpmág 24. 01. 2017, 21:17:14
S tím souhlasím a i jsi to potvrdil. Takže metatřídy jsou OK, když se nepoužívají. Jen vše ostatní nám zůstalo, takže na vývoj bych to moc neviděl :(
Název: Re:Dědičnost dnes
Přispěvatel: gll 24. 01. 2017, 21:45:22
S tím souhlasím a i jsi to potvrdil. Takže metatřídy jsou OK, když se nepoužívají. Jen vše ostatní nám zůstalo, takže na vývoj bych to moc neviděl :(

javamanova definice seriozního vývoje = vývoj v javě. Podle tvé definice se seriozní vývoj v ničem jiném dělat nedá.
Název: Re:Dědičnost dnes
Přispěvatel: lopata 24. 01. 2017, 21:46:50
Kde to má rozhraní? Kde je nějaké zapouzdření, když je vše public? Kde je nějaká dědičnost, když všechno je dynamické a nikdo mi nebrání cokoli přepsat? Tomu fakt říkáš jazyk na vývoj?

javamane, přejmenuj se zpátky a přestaň prudit pod jiným alter egem, všichni tě poznají, protože jsi pořád stejně neschopná lopata. Ty nejenom že nerozumíš Pythonu, ty nerozumíš ani té Javě. Pro tvoji informaci, private v javě (stejně jako __ v pythonu), je jen kontrakt, který může kdokoliv porušit. Nedělám si iluze, že bys to pochopil, protože pár řádek kódu je mimo tvoje možnosti, ale s private v javě se to má takhle:
Kód: [Vybrat]
import java.lang.reflect.*;

class Foo
{
    private String foo;

    public Foo()
    {
        foo = "foo";
    }

    public void print()
    {
        System.out.println(foo);
    }
}

class Bar
{
    public static void main(String[] args)
    {
        Foo foo = new Foo();
        foo.print();
        try
        {
            Field f = foo.getClass().getDeclaredField("foo");
            f.setAccessible(true);
            f.set(foo, "bar");
        }
        catch (Throwable e)
        {
            System.err.println(e);
        }
        foo.print();
    }
}
Co to asi vypíše?
Kód: [Vybrat]
java Bar
foo
bar
Takže už někam zalez a přestaň nás otravovat vlastní neschopností. Děkujeme.
Název: Re:Dědičnost dnes
Přispěvatel: balki 24. 01. 2017, 22:25:39
Kde to má rozhraní? Kde je nějaké zapouzdření, když je vše public? Kde je nějaká dědičnost, když všechno je dynamické a nikdo mi nebrání cokoli přepsat? Tomu fakt říkáš jazyk na vývoj?

javamane, přejmenuj se zpátky a přestaň prudit pod jiným alter egem, všichni tě poznají, protože jsi pořád stejně neschopná lopata. Ty nejenom že nerozumíš Pythonu, ty nerozumíš ani té Javě. Pro tvoji informaci, private v javě (stejně jako __ v pythonu), je jen kontrakt, který může kdokoliv porušit. Nedělám si iluze, že bys to pochopil, protože pár řádek kódu je mimo tvoje možnosti, ale s private v javě se to má takhle:
Kód: [Vybrat]
import java.lang.reflect.*;

class Foo
{
    private String foo;

    public Foo()
    {
        foo = "foo";
    }

    public void print()
    {
        System.out.println(foo);
    }
}

class Bar
{
    public static void main(String[] args)
    {
        Foo foo = new Foo();
        foo.print();
        try
        {
            Field f = foo.getClass().getDeclaredField("foo");
            f.setAccessible(true);
            f.set(foo, "bar");
        }
        catch (Throwable e)
        {
            System.err.println(e);
        }
        foo.print();
    }
}
Co to asi vypíše?
Kód: [Vybrat]
java Bar
foo
bar
Takže už někam zalez a přestaň nás otravovat vlastní neschopností. Děkujeme.

Toto je ukazkovy priklad nespravneho pouzitia reflexie v Jave.  Public fieldy a metody su preto public, lebo su sucastou garantovaneho rozhrania, ktore sa v buducnosti bude menit len minimalne. Kdezto private metody, tie sa neodporuca takto hackovat, lebo je velmi pravdepodobne, ze v triede v buducnosti nebudu.  Javova reflexia je velmi nepohodlna a ani sa moc nepouziva, rychlo by vas to prznenie kodu preslo. Ked chcete pouzivat taketo dirty hacky, odporucam uz radsej AspectJ. Naviac pouzivate C-ckove formatovanie na java kod, kazi mi to oci.
Název: Re:Dědičnost dnes
Přispěvatel: BoneFlute 24. 01. 2017, 22:50:28
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á.

Anemický model/objekt je taky objekt. Chyba programátora, že definuje debilní chování. Ale s OOP to nesouvisí ani ho neporušuje.

Primitivní typy v OOP neexistují. To je optimalizace Javy a spol. V OOP nemůžeš z objektu vybalit nějakou hodnotu primitivního typu. Můžeš jen objektu poslat zprávu a ona ti vrátí opět nějakou instanci nějakého objektu.

Podle mne není to vybalení nějaký problém. Prostě mám objekt, ten má stav, a ten stav si můžu vyserializovat - tedy to jsem si pojmenoval po svém to vybalení. No, a ten stav je samozřejmě taky složen z objektů (alespoň teoreticky).

Mě ta definice od JS přišla celkem trefná.
Název: Re:Dědičnost dnes
Přispěvatel: lopata 25. 01. 2017, 06:10:23
Toto je ukazkovy priklad nespravneho pouzitia reflexie v Jave.  Public fieldy a metody su preto public, lebo su sucastou garantovaneho rozhrania, ktore sa v buducnosti bude menit len minimalne. Kdezto private metody, tie sa neodporuca takto hackovat, lebo je velmi pravdepodobne, ze v triede v buducnosti nebudu.  Javova reflexia je velmi nepohodlna a ani sa moc nepouziva, rychlo by vas to prznenie kodu preslo. Ked chcete pouzivat taketo dirty hacky, odporucam uz radsej AspectJ. Naviac pouzivate C-ckove formatovanie na java kod, kazi mi to oci.

To nevadí, že jsi to nepochopil, zkus to znovu a lépe. Nápověda: private v javě NIC NEGARANTUJE, protože k tomu jde různými způsoby přistupovat jako k public. Je jedno, jestli reflexi říkáš hack nebo co si o ní myslíš, protože nemůžeš nijak rozumně zabránit, aby ji kdokoliv použil měnil tvoje private fieldy.

P.S.
Kód si můžu formátovat jak chci, mně třeba kazí oči Java kód  ;)
Název: Re:Dědičnost dnes
Přispěvatel: JS 25. 01. 2017, 09:18:25
Mě ta definice od JS přišla celkem trefná.

Nevim, jestli jsme si rozumeli, asi ano, slo mi predevsim o to, ze v OOP se predavaji data skryta v objektech (nelze k nim primo pristoupit), kdezto v FP se predavaji "naha" v tom smyslu, ze maji pomerne jasnou typovou definici. A to prirozene vede k tomu, ze se programy abstrahuji obracene - v FP se misto dat predavaji funkce, jejichz vnitrky (casti z kterych byly slozeny) jsou skryte.

V FP tak existuje flexibilita nalozit s temi daty jinak, nez by byly predurceny svymi metodami, a to je pravdepodobne to misto, kde jde o flexibilnejsi pristup.

A navic treba v Haskellu lze OOP realizovat pres typove tridy.
Název: Re:Dědičnost dnes
Přispěvatel: BoneFlute 25. 01. 2017, 13:16:32
ze maji pomerne jasnou typovou definici.

A navic treba v Haskellu lze OOP realizovat pres typove tridy.

Proto třeba osobně rozlišuju OOP/FP versus Typování jako dva různé koncepty.
Název: Re:Dědičnost dnes
Přispěvatel: noef 25. 01. 2017, 14:13:02
Mozna blba otazka, ale ja jsem myslel, ze kdyz knihovna v Haskellu nevyexportuje konstruktor, tak se k tomu nikdo krome knihovny nedostane. To neni zapouzdreni?
Název: Re:Dědičnost dnes
Přispěvatel: balki 25. 01. 2017, 14:43:09
Toto je ukazkovy priklad nespravneho pouzitia reflexie v Jave.  Public fieldy a metody su preto public, lebo su sucastou garantovaneho rozhrania, ktore sa v buducnosti bude menit len minimalne. Kdezto private metody, tie sa neodporuca takto hackovat, lebo je velmi pravdepodobne, ze v triede v buducnosti nebudu.  Javova reflexia je velmi nepohodlna a ani sa moc nepouziva, rychlo by vas to prznenie kodu preslo. Ked chcete pouzivat taketo dirty hacky, odporucam uz radsej AspectJ. Naviac pouzivate C-ckove formatovanie na java kod, kazi mi to oci.

To nevadí, že jsi to nepochopil, zkus to znovu a lépe. Nápověda: private v javě NIC NEGARANTUJE, protože k tomu jde různými způsoby přistupovat jako k public. Je jedno, jestli reflexi říkáš hack nebo co si o ní myslíš, protože nemůžeš nijak rozumně zabránit, aby ji kdokoliv použil měnil tvoje private fieldy.

P.S.
Kód si můžu formátovat jak chci, mně třeba kazí oči Java kód  ;)

Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Kto programuje v jave drzi sa istych konvencii http://www.oracle.com/technetwork/java/codeconvtoc-136057.html. Dokument je neudrziavany, ale este stale platny a riadi sa nim napriklad formatter v netbeans.
Název: Re:Dědičnost dnes
Přispěvatel: lopata 25. 01. 2017, 15:05:54
Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Kto programuje v jave drzi sa istych konvencii http://www.oracle.com/technetwork/java/codeconvtoc-136057.html. Dokument je neudrziavany, ale este stale platny a riadi sa nim napriklad formatter v netbeans.

Takže v Javě jde private porušit, ale nevadí to, protože kdo by to chtěl dělat, že. V Pythonu jde private porušit a je to hrozný problém, tím to ten jazyk naprosto diskvalifikuje... Typická Java logika Java zaslepence.

Ještě jednou, private v Javě i podtržitko v Pythonu mají úplně stejný význam, který říká:

"Tento field by se neměl měnit zvenku, není na to určený. Vím, že jde zvenku změnit, ale prosím nedělejte to. Něco by to mohlo ošklivě rozbít. Jestli ho opravdu budete měnit, dobře si to předtím rozmyslete, nenesu žádnou odpovědnost za nic. Děkuji za pochopení. S úctou Váš vývojář."

Uznávám, že napsat private je kratší. __ v pythonu je ještě kratší :D.
Název: Re:Dědičnost dnes
Přispěvatel: gll 25. 01. 2017, 15:15:34
Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Platí to stejné, co jsem psal o metaclassách. Stačí porušování podtržítkové konvence v projektu zakázat. Znovu se zeptám na kontrétní zkušenost. Kdy vám porušení podtržítkové konvence zkomplikovalo práci? Já vím, že nikdy, protože jste v pythonu nikdy neprogramoval.
Název: Re:Dědičnost dnes
Přispěvatel: ferren 25. 01. 2017, 15:19:44
zbezne jsem preletel zacatek a konec tohoto fora a prijde mi ze jsem z jine planety....

dedicnost urcite neni ani mrtva, ani nemoderni, samozrejme neni ani nezbytna....da se taky samozrejme nahradit spousta jinymi pristupy, vse je to ale jen uplne stejnej syntaktickej cukr, podstatna cast je uplne identicka a to je HIERARCHIE ZASTUPITELNOSTI.

kdyz je tato hierachie spravna, dedicnost je velice pohodlna a ucinna...a naopak. to plati ale pro vsechny systemy, co maji ambici se pokouset ji nahradit.

takze se vse jen redukuje na schopnost vytvareni spravnych hierarchii pro KONKRETNI aplikaci. viz uz probranej virtualni problem ctverec vs obdelnik, kde me nenapada moc aplikaci (kreslicich, sumulacnich, numerickych) kde by vubec mel objekt ctverec rozumny duvod sve existence.
 teprv v aplikacich ktere objekt ctverec z nejakeho duvodu fakt potrebuji je jeho vztah k obdelniku zcela evidentne jednoznacny a vyplyva z duvodu jeho potreby existence...






Název: Re:Dědičnost dnes
Přispěvatel: zboj 25. 01. 2017, 15:30:01
zbezne jsem preletel zacatek a konec tohoto fora a prijde mi ze jsem z jine planety....

dedicnost urcite neni ani mrtva, ani nemoderni, samozrejme neni ani nezbytna....da se taky samozrejme nahradit spousta jinymi pristupy, vse je to ale jen uplne stejnej syntaktickej cukr, podstatna cast je uplne identicka a to je HIERARCHIE ZASTUPITELNOSTI.

kdyz je tato hierachie spravna, dedicnost je velice pohodlna a ucinna...a naopak. to plati ale pro vsechny systemy, co maji ambici se pokouset ji nahradit.

takze se vse jen redukuje na schopnost vytvareni spravnych hierarchii pro KONKRETNI aplikaci. viz uz probranej virtualni problem ctverec vs obdelnik, kde me nenapada moc aplikaci (kreslicich, sumulacnich, numerickych) kde by vubec mel objekt ctverec rozumny duvod sve existence.
 teprv v aplikacich ktere objekt ctverec z nejakeho duvodu fakt potrebuji je jeho vztah k obdelniku zcela evidentne jednoznacny a vyplyva z duvodu jeho potreby existence...
V raytracingu a obecně 3D grafice se geometrie používá, i 2D objekty. V diskusi šlo ale spíše o princip. Obecně jde v kódu především o polymorfismus, jehož lze dosáhnout dědičností jako jednou z metod. Co bylo kritizováno je zneužití dědičnosti k něčemu jinému.
Název: Re:Dědičnost dnes
Přispěvatel: ferren 25. 01. 2017, 15:33:29
zbezne jsem preletel zacatek a konec tohoto fora a prijde mi ze jsem z jine planety....

dedicnost urcite neni ani mrtva, ani nemoderni, samozrejme neni ani nezbytna....da se taky samozrejme nahradit spousta jinymi pristupy, vse je to ale jen uplne stejnej syntaktickej cukr, podstatna cast je uplne identicka a to je HIERARCHIE ZASTUPITELNOSTI.

kdyz je tato hierachie spravna, dedicnost je velice pohodlna a ucinna...a naopak. to plati ale pro vsechny systemy, co maji ambici se pokouset ji nahradit.

takze se vse jen redukuje na schopnost vytvareni spravnych hierarchii pro KONKRETNI aplikaci. viz uz probranej virtualni problem ctverec vs obdelnik, kde me nenapada moc aplikaci (kreslicich, sumulacnich, numerickych) kde by vubec mel objekt ctverec rozumny duvod sve existence.
 teprv v aplikacich ktere objekt ctverec z nejakeho duvodu fakt potrebuji je jeho vztah k obdelniku zcela evidentne jednoznacny a vyplyva z duvodu jeho potreby existence...
V raytracingu a obecně 3D grafice se geometrie používá, i 2D objekty. V diskusi šlo ale spíše o princip. Obecně jde v kódu především o polymorfismus, jehož lze dosáhnout dědičností jako jednou z metod. Co bylo kritizováno je zneužití dědičnosti k něčemu jinému.

vsak pisu, tam kde je treba, jsou zrejme zaroven i jeho vazby proc.....btw ja prave prochazim ze sveta 3d grafiky a v zadnym enginu, od vlastniho pres nekolik mainstreamovych komercnich ctverec nevidim, ale to je asi zas tradicne offtopic ;-)
Název: Re:Dědičnost dnes
Přispěvatel: balki 25. 01. 2017, 17:18:44
Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Platí to stejné, co jsem psal o metaclassách. Stačí porušování podtržítkové konvence v projektu zakázat. Znovu se zeptám na kontrétní zkušenost. Kdy vám porušení podtržítkové konvence zkomplikovalo práci? Já vím, že nikdy, protože jste v pythonu nikdy neprogramoval.

Ale, programoval som v pythone nejake drobnosti do roboty. V praxi sa vacsinou pouziva na skriptovanie, na nic serioznejsie.  Plus som si skusal, ako sa v tom robi s opengl. Podtrzitkova konvencia sa mi zda prinajmensom nemudra. Je to nachylne k tomu, ze niekto si siahne tam, kam nema z lenivosti, alebo nevedomosti.

Z jasnovidectva ste asi nemali dobre znamky.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 25. 01. 2017, 22:20:10
Podtrzitkova konvencia sa mi zda prinajmensom nemudra. Je to nachylne k tomu, ze niekto si siahne tam, kam nema z lenivosti, alebo nevedomosti.

Pane bože, ty to vidíš!
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 08:16:36
On je mutable v ramci objektu, ktery je ale zvenci black box. Ono zapouzdreni neni, ze se vsechny promenne udelaji private a napisi k tomu gettery a settery. Zapouzdreni znamena, ze nevidis z venci, jak to uvnitr funguje a neleakuje ven implementace. Takze pokud to je vhodne tam klidne je public promenna a at si s tim kazdy dela co chce.

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Navenek se mutable projevuje jako reference opacity, jak by řekli funkcionáři. :) Jsem tu jeden z posledních, komu má smysl vysvětlovat zapouzdření.
Observer je jen jedním ze způsobů komunikace mezi objekty/aktory, tvrzení, že se vzájemně neznají, je nesmysl, pak by to nemohlo fungovat. Máte v tom kapinku nejasno.
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 08:18:12
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.

Tahle odpověď mi připomíná kamaráda, když jsme hráli pingpong: "A kdo vyhraje?" "No přece ten, kdo bude mít nejvíc bodů."
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 08:20:13
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.

To je nasměrování - děkuji, kouknu (i když ten aparát vypadá docela nepřehledně...).
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 08:23:37
Ja psal jak to bylo puvodne navrzeny a nekomu se taky zdalo, ze je to komplikovany a vznikla... Java

Java vznikla, aby céčkaři mohli začít používat vyšší abstrakci a "objekty" a neposrali se z toho. Nehledejte složitosti, kde nejsou.
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 08:26:11

Tak to je super a máme z toho nejpopulárnější jazyk. Tak si to představuju.


Takovej Justin Bieber je taky nejpopularnejsi...

Asi tak. Nejpoužívanější a kvalitní můžou být (a obvykle jsou) zcela nesouvisející pojmy. Já bych se rád přidržel té kvality.
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 08:40:19
Dynamické a použitelné jsou i např. Ruby nebo Python.
Právě ani jeden není. Python je na malé skriptíky a Ruby také. Oba se dají dost dobře použít na webíky, ale to je tak všechno. Přesně ta jejich dynamičnost je vyřazuje z použití. Také metatřídy v Pythonu to všechno jen dodělají :D Jako nic proti nim, jen to je přesně ten příklad jazyků, které použít na větší věci nejde. Proto se tam ani nepoužívají. Kdyby ta dynamičnost byla tak úžasná, tak to nepoužívají hlavně admini, kteří vyvíjet neumí.

Tohleto tady nezavádějte, každý jazyk je dobrý nejen na něco jiného, ale hlavně pro někoho jiného. Někdo má rád bezpečí typové kontroly překladače, někoho sere slabá abstrakce a složitá syntaxe. Jestli vám to nejde, není to jazyk pro vás.
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 09:10:45
...Také metatřídy v Pythonu to všechno jen dodělají...

Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80 (https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80). Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 09:14:29
Za prvé můžeš mít neschopné kolegy, kteří je nacpou všude...

Ti do metatříd nikdy nepůjdou, budou mít co dělat, aby přišli na to, jak v Pythonu programovat jako v C++.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 10:09:44
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.

To je nasměrování - děkuji, kouknu (i když ten aparát vypadá docela nepřehledně...).
Ono to je poměrně přehledné, ale moc abstraktní. Doporučuju něco o monádách pro vývojáře než knihu pro matematiky (aspoň pro začátek). Nejlépe to člověk asi pochopí z příkladů.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 10:11:16
...Také metatřídy v Pythonu to všechno jen dodělají...

Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80 (https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80). Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?
ObjC :)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 10:12:04
Ja psal jak to bylo puvodne navrzeny a nekomu se taky zdalo, ze je to komplikovany a vznikla... Java

Java vznikla, aby céčkaři mohli začít používat vyšší abstrakci a "objekty" a neposrali se z toho. Nehledejte složitosti, kde nejsou.
Nebylo to spíše pro to, aby mohli psát fungující kód i necéčkaři? ;)
Název: Re:Dědičnost dnes
Přispěvatel: bob 26. 01. 2017, 11:25:47
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.

To je nasměrování - děkuji, kouknu (i když ten aparát vypadá docela nepřehledně...).
Ono to je poměrně přehledné, ale moc abstraktní. Doporučuju něco o monádách pro vývojáře než knihu pro matematiky (aspoň pro začátek). Nejlépe to člověk asi pochopí z příkladů.

Pro cloveka, co nikdy nevidel funkcionalni programovani je to naprosto nepochopitelne. Dostat odpoved Monady na takovy dotaz, je stejne jako, kdyz se ctyrlete dite zepta proc je v noci tma a vy mu reknete: geometrie trirozmerneho prostoru.

Klasicky akademicky pristup nasich skol...

Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.

Tahle odpověď mi připomíná kamaráda, když jsme hráli pingpong: "A kdo vyhraje?" "No přece ten, kdo bude mít nejvíc bodů."

To je nejspis prvni pravidlo ne? Nepsal jste, ze FP neznate? Ale, lepsi je to zacit resit pekne od konce, problemem fyziky rotace micku a jehova vlivu na dopad na stul.


Java vznikla, aby céčkaři mohli začít používat vyšší abstrakci a "objekty" a neposrali se z toho. Nehledejte složitosti, kde nejsou.
Nebylo to spíše pro to, aby mohli psát fungující kód i necéčkaři? ;)

Tak se jim to moc nepovedlo. Java je v Guinessove knize. Na Hello World do terminal musite napsat nejvic radku kodu ze vsech jazyku.
Název: Re:Dědičnost dnes
Přispěvatel: noef 26. 01. 2017, 11:30:36
Tak se jim to moc nepovedlo. Java je v Guinessove knize. Na Hello World do terminal musite napsat nejvic radku kodu ze vsech jazyku.

To je lez, se podivejte na Java vs. C verzi treba:

Kód: [Vybrat]
public class Java {
public static void main(String[] args) {
System.out.println("Hello World");
}
}

Kód: [Vybrat]
#include<stdio.h>

int main() {
printf("Hello World\n");
return 0;
}
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 12:13:27
Zprávy mají s funkcemi společnou jedinou věc, a to, že synchronně vracejí odpověď. Tím jejich podobnost končí.

To je minimálně zavádějící tvrzení.

1. funkce jsou statické, zprávy jsou akce
...

Tady jsme si spíš nerozuměli, předpokládal jsem, že se porovnává funkce z imperativních jazyků (tj. v podstatě procedura) s objektovým posíláním. Funkcionální funkci (tj. v podstatě matematickou funkci) jsem na mysli neměl.

2. zprávy nemusí být synchronní

...a dokonce je lepší, když defaultně nejsou, protože sesynchronizovat asynchronní události je v dobře navrženém jazyce triviální (kód v jazyce Elixir):
Kód: [Vybrat]
...

To vypadá dobře. I když implementovat asynchronní v synchronním jde tady.

3. odeslání zprávy nemusí nic "vracet" nebo může "vracet" víc hodnot postupně
...

To už je věcí implementace na druhé straně, to bych tu nerozebíral. Ale vypadá to zajímavě.

Immutable je immutable, takže pokud si pod "změnou stavu" představuješ změnu in situ, tak nijak. Jinak to ale může vypadat třeba takhle (jeden příklad z jiného světa, když odpověď "monády" ti nestačila):

Kód: [Vybrat]
# zjednodušený ilustrační příklad, v reálu by to vypadalo trochu jinak
defmodule StateHolder do
  # tahle funkce spustí agenta držícího stav
  def start_link() do
    # spustí funkci loop s parametry [0] v novém vlákně
    spawn_link(fn -> loop(0) end)
  end

  def loop(state) do
    receive do
      {:add,k} ->
        new_state = state + k
        IO.puts "stav se meni z #{state} na #{new_state}"
        loop(new_state)
      {:get_state,pid} ->
        send(pid,{:state_is,state})
        loop(state)
    end
  end

end

Monády mi stačila, jen jsem je nestihl prostudovat.
Pěkně jste napsal ten příklad (včetně použití). Jestli to chápu správně, tak z něj jde znát, že stav je pochopitelně v modulu přítomen, ale ve formě hodnoty state vznikající v novém kontextu při volání funkce loop (new_state). Zde odhaduju, že volání loop není jako call (rekurzivní), ale spíše něco jako goto, any bylo možno zahazovat opuštěný kontext předchozího volání funkce (jinak by se zaplnila paměť). Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable. Tzn. tvrzení, že v FP je vše immutable, asi nebude pravdivé. Dále předpokládám, že jsou hodnoty při volání funkce či posílání zprávy předávány odkazem, jinak by celé toto čarování nemělo smysl.
Název: Re:Dědičnost dnes
Přispěvatel: bob 26. 01. 2017, 12:30:47

Pěkně jste napsal ten příklad (včetně použití). Jestli to chápu správně, tak z něj jde znát, že stav je pochopitelně v modulu přítomen, ale ve formě hodnoty state vznikající v novém kontextu při volání funkce loop (new_state). Zde odhaduju, že volání loop není jako call (rekurzivní), ale spíše něco jako goto, any bylo možno zahazovat opuštěný kontext předchozího volání funkce (jinak by se zaplnila paměť). Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable. Tzn. tvrzení, že v FP je vše immutable, asi nebude pravdivé. Dále předpokládám, že jsou hodnoty při volání funkce či posílání zprávy předávány odkazem, jinak by celé toto čarování nemělo smysl.

Ano v immutable je to jen z pohledu programatora. Pocitac samozrejme pamet fyzicky meni.
Toto je implementovano jako tail-call optimisation. Kdyz je volani sebe sama jako posledni a neni tam zadna hodnota, ktera se rekurzivne vraci (return 1+ callme(n) vs return callme(n+1)), tak neni nutne alokovat na stacku novou pamet. Lze pouzit stejny stack s jakym byl zavolan pro nove volani.
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 12:38:18
Anemický model/objekt je taky objekt. Chyba programátora, že definuje debilní chování. Ale s OOP to nesouvisí ani ho neporušuje.

I ten nejjednodušší objekt mívá nějaké chování, jestliže jej nemá, je třeba se zamyslet, zda není něco špatně. Téměř vždy je anemický model objekt zdegenerovaný do céčkového recordu jen proto, aby s ním šlo dělat zvenku.

Primitivní typy v OOP neexistují. To je optimalizace Javy a spol. V OOP nemůžeš z objektu vybalit nějakou hodnotu primitivního typu. Můžeš jen objektu poslat zprávu a ona ti vrátí opět nějakou instanci nějakého objektu.

To jsem přece napsal proto, aby si někteří uvědomili, že jazyk, který pracuje s primitivy (hodnotami, ne lidmi) není pure object language, jestli je vůbec OOP. Vy mi chcete vysvětlovat, co je to čisté OP? To nemyslíte vážně!

Podle mne není to vybalení nějaký problém. Prostě mám objekt, ten má stav, a ten stav si můžu vyserializovat - tedy to jsem si pojmenoval po svém to vybalení. No, a ten stav je samozřejmě taky složen z objektů (alespoň teoreticky).

Serializace je výstup objektu jako každý jiný, pak je "vybalení" i výstup osoba.prijmeni() -> "Jebáček".
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 13:11:06
...Ještě jednou, private v Javě i podtržitko v Pythonu mají úplně stejný význam, který říká:

"Tento field by se neměl měnit zvenku, není na to určený. Vím, že jde zvenku změnit, ale prosím nedělejte to. Něco by to mohlo ošklivě rozbít. Jestli ho opravdu budete měnit, dobře si to předtím rozmyslete, nenesu žádnou odpovědnost za nic. Děkuji za pochopení. S úctou Váš vývojář."
...

Není to to samé - v Javě je technologická viditelnost - do private se mimo třídu (ne objekt!) díky překladači nijak nedá. V Pythonu je psychologická - "__" znamená: "Ahoj! Já jsem metoda private, ale ve skutečnosti až tak moc private nejsem, vlastně nejsem ani protected (tatík byl líný a nedomyslel to), ale to nevadí, budeme dělat, jakože ano, a doufat, že si toho nikdo nevšimne. Děkuji, že děláte dobrou věc a dodržujete naši dohodu o neviditelnosti. Ještě jednou děkuji. Ahoj!"

Já v tom teda rozdíl vidím.
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 13:12:51
...Stačí porušování podtržítkové konvence v projektu zakázat...

A to funguje na úrovni překladače nebo běhu?
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 13:18:38
...Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?
ObjC :)

Tak samozřejmě, ale víme, proč jsem to napsal...  ;)
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 13:21:51

Java vznikla, aby céčkaři mohli začít používat vyšší abstrakci a "objekty" a neposrali se z toho. Nehledejte složitosti, kde nejsou.
Nebylo to spíše pro to, aby mohli psát fungující kód i necéčkaři? ;)
To by přece použili Smalltalk.  ;)
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 13:23:42
Tak se jim to moc nepovedlo. Java je v Guinessove knize. Na Hello World do terminal musite napsat nejvic radku kodu ze vsech jazyku.

To jako System.out.println("Nazdar."); ?
Název: Re:Dědičnost dnes
Přispěvatel: SB 26. 01. 2017, 13:30:28
Ano v immutable je to jen z pohledu programatora. Pocitac samozrejme pamet fyzicky meni.
Toto je implementovano jako tail-call optimisation. Kdyz je volani sebe sama jako posledni a neni tam zadna hodnota, ktera se rekurzivne vraci (return 1+ callme(n) vs return callme(n+1)), tak neni nutne alokovat na stacku novou pamet. Lze pouzit stejny stack s jakym byl zavolan pro nove volani.

Tail-call je o optimizaci návratu po návratu. V uvedeném příkladu zavolání loop(něco) se odnikud nevrací, naopak buďto je to rekurze a zásobník roste, nebo je to skok a stejně je třeba vytvořit nový kontext, ale starý je zahoditelný.
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 13:31:47
...Také metatřídy v Pythonu to všechno jen dodělají...

Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80 (https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80). Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?

V jiné diskuzi se řešila typová kontrola a vynucení implementace abstraktních metod. K tomu jsou metatřídy ideální.
Název: Re:Dědičnost dnes
Přispěvatel: Sten 26. 01. 2017, 13:43:35
...Také metatřídy v Pythonu to všechno jen dodělají...

Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80 (https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80). Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?

Java (https://projectlombok.org/features/experimental/ExtensionMethod.html) :)
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 13:56:38
...Také metatřídy v Pythonu to všechno jen dodělají...

Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80 (https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80). Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?

Java (https://projectlombok.org/features/experimental/ExtensionMethod.html) :)

to je něco úplně jiného.
Název: Re:Dědičnost dnes
Přispěvatel: bob 26. 01. 2017, 14:11:18
Ano v immutable je to jen z pohledu programatora. Pocitac samozrejme pamet fyzicky meni.
Toto je implementovano jako tail-call optimisation. Kdyz je volani sebe sama jako posledni a neni tam zadna hodnota, ktera se rekurzivne vraci (return 1+ callme(n) vs return callme(n+1)), tak neni nutne alokovat na stacku novou pamet. Lze pouzit stejny stack s jakym byl zavolan pro nove volani.

Tail-call je o optimizaci návratu po návratu. V uvedeném příkladu zavolání loop(něco) se odnikud nevrací, naopak buďto je to rekurze a zásobník roste, nebo je to skok a stejně je třeba vytvořit nový kontext, ale starý je zahoditelný.

def loop(neco) do   je definice funkce.
zavolani loop(neco) je rekurzivni volani funkce a zaroven se vraci i jeji vysledek. Tam neni napsano return, ale jde si ho tam predstavit. Vysledek posledniho prikazu se automaticky vraci, neni nutne tam psat vsude return.

To, ze se nezvetsuje zasobnik a nepretece, je diky tail-call optimizaci. Protoze fce vraci vyhradne vysledek dalsiho volani a nevraci zadnou svou lokalni promennou (cela rekurze ma strejny vysledek jako posledni volani, neni nutne si pamatovat cokoliv mezi tim), je vrsek stacku zahozen a stejne misto se pouzije pro dalsi volani fce loop(neco).

Naproti tomu napr. v C++, by se vrsek stacku nezahodil a pro nove volani by se nad tim alokovala nova pamet a brzy by dosla.

Zadny ze soucasnych nefunkcionalnich jazyku tail call neumi (c++,java, c#, atp..), krom JavaScript (ES6).
Název: Re:Dědičnost dnes
Přispěvatel: noef 26. 01. 2017, 15:01:10
Zadny ze soucasnych nefunkcionalnich jazyku tail call neumi (c++,java, c#, atp..), krom JavaScript (ES6).

To jako ze JS neni funkcionalni? Jiste, neni ciste (pure) funkcionalni, ale funkcionalni IMO je. Podobne Scala, ta ma v urcitych pripadech tail-call optimalizaci a take neni ciste funckionalnim jazykem.
Název: Re:Dědičnost dnes
Přispěvatel: Sten 26. 01. 2017, 15:06:39
to je něco úplně jiného.

Je to stejný výsledek bez metatříd. Tohle jsou tedy jen rozšiřující metody, ukládání do DB dělá třeba Hibernate, třídy lze měnit za běhu JVM přes ClassLoader (https://stackoverflow.com/a/14317506/4538344). Nemá to tedy všechny schopnosti metatříd (třeba nejdou měnit již instancované objekty bez jejich znovuvytvoření, což jde přes ten Hibernate), ale ty zmíněné to umí.

Naproti tomu napr. v C++, by se vrsek stacku nezahodil a pro nove volani by se nad tim alokovala nova pamet a brzy by dosla.

MSVC++, GCC i LLVM dělají tail-call optimizace a takovouto rekurzi předvedou na for loop, a to dokonce i nepřímou (pokud jsou definice obou funkcí dostupné ve stejném kontextu).
Název: Re:Dědičnost dnes
Přispěvatel: bob 26. 01. 2017, 15:15:15
Zadny ze soucasnych nefunkcionalnich jazyku tail call neumi (c++,java, c#, atp..), krom JavaScript (ES6).

To jako ze JS neni funkcionalni? Jiste, neni ciste (pure) funkcionalni, ale funkcionalni IMO je. Podobne Scala, ta ma v urcitych pripadech tail-call optimalizaci a take neni ciste funckionalnim jazykem.

Jo je :). Ja tam mel puvodne beznych jazyku, pak to prepsal.
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 15:52:15
to je něco úplně jiného.

Je to stejný výsledek bez metatříd. Tohle jsou tedy jen rozšiřující metody, ukládání do DB dělá třeba Hibernate, třídy lze měnit za běhu JVM přes ClassLoader (https://stackoverflow.com/a/14317506/4538344). Nemá to tedy všechny schopnosti metatříd (třeba nejdou měnit již instancované objekty bez jejich znovuvytvoření, což jde přes ten Hibernate), ale ty zmíněné to umí.

k tomuhle nejsou metaclassy vůbec potřeba. To je v dynamických jazycích trivialita.
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 16:35:46
...Stačí porušování podtržítkové konvence v projektu zakázat...

A to funguje na úrovni překladače nebo běhu?

Linter na to upozorní.

Na úrovni běhu by to šlo zakázat třeba právě tou metaclassou.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 18:16:13

Java vznikla, aby céčkaři mohli začít používat vyšší abstrakci a "objekty" a neposrali se z toho. Nehledejte složitosti, kde nejsou.
Nebylo to spíše pro to, aby mohli psát fungující kód i necéčkaři? ;)
To by přece použili Smalltalk.  ;)
Nebo spíše ObjC, to kombinuje rychlost Smalltalku a paměťovou bezpečnost céčka ;)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 19:31:25
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.

To je nasměrování - děkuji, kouknu (i když ten aparát vypadá docela nepřehledně...).
Ono to je poměrně přehledné, ale moc abstraktní. Doporučuju něco o monádách pro vývojáře než knihu pro matematiky (aspoň pro začátek). Nejlépe to člověk asi pochopí z příkladů.

Pro cloveka, co nikdy nevidel funkcionalni programovani je to naprosto nepochopitelne. Dostat odpoved Monady na takovy dotaz, je stejne jako, kdyz se ctyrlete dite zepta proc je v noci tma a vy mu reknete: geometrie trirozmerneho prostoru.

Klasicky akademicky pristup nasich skol...
Univerzity jsou tak nějak z definice akademické...
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám tutoriál na webu, je jich tam habaděj (i Wikipedie to podává celkem srozumitelně). Navíc monády jsou jedním z konceptů, které jinak než "akademicky" vysvětlit nejdou. Pokud to někomu vadí, nemá v IT co dělat.
Název: Re:Dědičnost dnes
Přispěvatel: karel 26. 01. 2017, 20:08:28
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.

To je nasměrování - děkuji, kouknu (i když ten aparát vypadá docela nepřehledně...).
Ono to je poměrně přehledné, ale moc abstraktní. Doporučuju něco o monádách pro vývojáře než knihu pro matematiky (aspoň pro začátek). Nejlépe to člověk asi pochopí z příkladů.

Pro cloveka, co nikdy nevidel funkcionalni programovani je to naprosto nepochopitelne. Dostat odpoved Monady na takovy dotaz, je stejne jako, kdyz se ctyrlete dite zepta proc je v noci tma a vy mu reknete: geometrie trirozmerneho prostoru.

Klasicky akademicky pristup nasich skol...
Univerzity jsou tak nějak z definice akademické...
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám tutoriál na webu, je jich tam habaděj (i Wikipedie to podává celkem srozumitelně). Navíc monády jsou jedním z konceptů, které jinak než "akademicky" vysvětlit nejdou. Pokud to někomu vadí, nemá v IT co dělat.
Nevim, mě na tom nic složitého nepřijde a dá se to snadno pochopit i bez znalostí tuny teorie. IMHO to spousta lidí používá v praxi i mimo FP aniž by znali pojem monáda (což bude asi největší problém, že neznají pojem a ne myšlenku). Např. optional template v boostu.
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 20:11:58
Univerzity jsou tak nějak z definice akademické...
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám tutoriál na webu, je jich tam habaděj (i Wikipedie to podává celkem srozumitelně). Navíc monády jsou jedním z konceptů, které jinak než "akademicky" vysvětlit nejdou. Pokud to někomu vadí, nemá v IT co dělat.

Těžko se k tomu hledá motivace. Monády řeší problém, který neexistuje. Většina vědních oborů považuje jednoduchá řešení za elegantní a hledá právě jednoduchá řešení. SW inženýrství je výjimka. Vyžívá se v uměle složitých řešeních jednoduchých problémů. Proto je pro spoustu lidí jeho studium nepřístupné.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 20:55:04
Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.
U monád se nic nezahazuje.

To je nasměrování - děkuji, kouknu (i když ten aparát vypadá docela nepřehledně...).
Ono to je poměrně přehledné, ale moc abstraktní. Doporučuju něco o monádách pro vývojáře než knihu pro matematiky (aspoň pro začátek). Nejlépe to člověk asi pochopí z příkladů.

Pro cloveka, co nikdy nevidel funkcionalni programovani je to naprosto nepochopitelne. Dostat odpoved Monady na takovy dotaz, je stejne jako, kdyz se ctyrlete dite zepta proc je v noci tma a vy mu reknete: geometrie trirozmerneho prostoru.

Klasicky akademicky pristup nasich skol...
Univerzity jsou tak nějak z definice akademické...
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám tutoriál na webu, je jich tam habaděj (i Wikipedie to podává celkem srozumitelně). Navíc monády jsou jedním z konceptů, které jinak než "akademicky" vysvětlit nejdou. Pokud to někomu vadí, nemá v IT co dělat.
Nevim, mě na tom nic složitého nepřijde a dá se to snadno pochopit i bez znalostí tuny teorie. IMHO to spousta lidí používá v praxi i mimo FP aniž by znali pojem monáda (což bude asi největší problém, že neznají pojem a ne myšlenku). Např. optional template v boostu.
Tak nějak. Každý se k tomu časem dopracuje víceméně automaticky. K většině užitečných konceptů člověk ostatně dojde, protože je v nějaké situaci najednou potřebuje, a nemělo by překvapovat, že to je "znovuobjevení kola". Možná je i lepší přijít na něco sám za běhu, než se snažit naučit teorii z knih.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 20:56:23
Univerzity jsou tak nějak z definice akademické...
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám tutoriál na webu, je jich tam habaděj (i Wikipedie to podává celkem srozumitelně). Navíc monády jsou jedním z konceptů, které jinak než "akademicky" vysvětlit nejdou. Pokud to někomu vadí, nemá v IT co dělat.

Těžko se k tomu hledá motivace. Monády řeší problém, který neexistuje. Většina vědních oborů považuje jednoduchá řešení za elegantní a hledá právě jednoduchá řešení. SW inženýrství je výjimka. Vyžívá se v uměle složitých řešeních jednoduchých problémů. Proto je pro spoustu lidí jeho studium nepřístupné.
Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 21:20:31
Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.

OK. V dogmatickém FP je to nepostradatelný koncept. Nabízí se otázka, jestli dogmatické FP nevytváří víc problémů než řeší. Argument s formálním dokazováním správnosti FP programů má váhu jen u programů, kde tu správnost skutečně někdo dokazuje. Dost se mi líbí přístup jazyka Elixir, který zde byl zmíněn. Umožňuje psát FP stylem, ale nehází zbytečně klacky pod nohy.
Název: Re:Dědičnost dnes
Přispěvatel: pr 26. 01. 2017, 21:30:20
A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 21:33:27
Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.

OK. V dogmatickém FP je to nepostradatelný koncept. Nabízí se otázka, jestli dogmatické FP nevytváří víc problémů než řeší. Argument s formálním dokazováním správnosti FP programů má váhu jen u programů, kde tu správnost skutečně někdo dokazuje. Dost se mi líbí přístup jazyka Elixir, který zde byl zmíněn. Umožňuje psát FP stylem, ale nehází zbytečně klacky pod nohy.
K tomu se nějak vyjadřovat nechci, ostatně sám FP používám jen v jazycích, které jsou převážně OO, a jsem zastáncem spíš pragmatického přístupu. Nicméně zrovna u monád mám pocit, že se poměrně rozšířily i mimo čisté FP (byť se jim většinou říká jinak nebo nijak).
Název: Re:Dědičnost dnes
Přispěvatel: v 26. 01. 2017, 22:00:45
Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.

OK. V dogmatickém FP je to nepostradatelný koncept. Nabízí se otázka, jestli dogmatické FP nevytváří víc problémů než řeší. Argument s formálním dokazováním správnosti FP programů má váhu jen u programů, kde tu správnost skutečně někdo dokazuje. Dost se mi líbí přístup jazyka Elixir, který zde byl zmíněn. Umožňuje psát FP stylem, ale nehází zbytečně klacky pod nohy.
který mainstreamový funkcionální jazyk klacky pod nohy hází?
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 22:04:54
A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

S mnoha body souhlasím. OOP dogmatismus je ještě horší. Snaha o čistě FP kód má racionální základ. Snaha o čistě OOP kód je jen čistý fanatismus.

Erlang je v některých ohledech přísnější než Elixir. Elixir má narozdíl od Erlangu mutable proměnné. Což považuji za výhodu.

Nechci vyvolávat flame. Berte to jako názor čistého praktika původem z trochu jiného oboru. Možná mi něco uniká.
Název: Re:Dědičnost dnes
Přispěvatel: gll 26. 01. 2017, 22:50:23
který mainstreamový funkcionální jazyk klacky pod nohy hází?

to už tu bylo probíráno mnohokrát.

před chvílí se v jiném vlákně někdo ptal na dijkstrův algoritmus, tak třeba to

https://rosettacode.org/wiki/Dijkstra%27s_algorithm#Haskell

tam se musí používat monády jen protože FP.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 23:42:39
A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

S mnoha body souhlasím. OOP dogmatismus je ještě horší. Snaha o čistě FP kód má racionální základ. Snaha o čistě OOP kód je jen čistý fanatismus.

Erlang je v některých ohledech přísnější než Elixir. Elixir má narozdíl od Erlangu mutable proměnné. Což považuji za výhodu.

Nechci vyvolávat flame. Berte to jako názor čistého praktika původem z trochu jiného oboru. Možná mi něco uniká.
Osobně ani nevím, co by "čisté OOP" mělo přesně být. Nicméně být "praktikem" se většinou vyplácí.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 26. 01. 2017, 23:47:34
který mainstreamový funkcionální jazyk klacky pod nohy hází?

to už tu bylo probíráno mnohokrát.

před chvílí se v jiném vlákně někdo ptal na dijkstrův algoritmus, tak třeba to

https://rosettacode.org/wiki/Dijkstra%27s_algorithm#Haskell

tam se musí používat monády jen protože FP.
Tak zase abychom nekřivdili FP, každý, kdo používá seznam (v jakémkoliv jazyce), používá monády (i když to většina netuší). Jsou to prostě potvory všudypřítomné a myslím, že většinu lidí děsí jen ten termín, jinak je vesele používají všude možně. Navíc i v "čistém" FP se většinou používá syntaktický cukr, díky němuž kód vypadá celkem procedurálně.
Název: Re:Dědičnost dnes
Přispěvatel: noef 27. 01. 2017, 06:54:31
Monády jsou právě příklad jednoduchého a elegantního konceptu. Navíc v FP nepostradatelného.

OK. V dogmatickém FP je to nepostradatelný koncept. Nabízí se otázka, jestli dogmatické FP nevytváří víc problémů než řeší. Argument s formálním dokazováním správnosti FP programů má váhu jen u programů, kde tu správnost skutečně někdo dokazuje. Dost se mi líbí přístup jazyka Elixir, který zde byl zmíněn. Umožňuje psát FP stylem, ale nehází zbytečně klacky pod nohy.

Tak pokud monady povazujete za hazeni klacku pod nohy (monady jsou FP koncept), tak pak vam (se stejnou logikou) Java hazi klacky pod nohy tim, ze chce mit vsude ty proklate objekty ;D.
Název: Re:Dědičnost dnes
Přispěvatel: v 27. 01. 2017, 07:52:16
který mainstreamový funkcionální jazyk klacky pod nohy hází?

to už tu bylo probíráno mnohokrát.

před chvílí se v jiném vlákně někdo ptal na dijkstrův algoritmus, tak třeba to

https://rosettacode.org/wiki/Dijkstra%27s_algorithm#Haskell

tam se musí používat monády jen protože FP.
slovy klasika - tohle není ani špatně :)
jak už bylo napsáno, v javě se musí používat objekty jenom protože OOP
Název: Re:Dědičnost dnes
Přispěvatel: Jozko 27. 01. 2017, 08:55:15
ty proklate objekty  ;D
Název: Re:Dědičnost dnes
Přispěvatel: bob 27. 01. 2017, 09:17:33
Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám

Ja teda nevim, ja puvodni otazku pochopil tak, ze jak se da zmenit stav, kdyz je vse immutable. Zmenou stavu rozumim, jak muzu napr. zmenit hodnotu ve formulari. Problem se resi tak, ze se stara hodnota zahodi a vytvori se nova a ta se zobrazi.

Na tohle snad monady nepotrebujete?

Název: Re:Dědičnost dnes
Přispěvatel: JS 27. 01. 2017, 09:22:36
Mozna blba otazka, ale ja jsem myslel, ze kdyz knihovna v Haskellu nevyexportuje konstruktor, tak se k tomu nikdo krome knihovny nedostane. To neni zapouzdreni?

To mas pravdu, to me nenapadlo. To se samozrejme da brat jako zapouzdreni a je to v poradku.

Ale je tady jeden zasadni rozdil - v OOP je to skryvani nutne, protoze objekty jsou mutabilni, a neni mozne dovolit ostatnim s nimi zevne nakladat. Ale hodnoty predavane v FP jsou imutabilni, tudiz v podstate neni duvod je takto skryvat (vyjma snad situaci, kde uvnitr kodu fakticky dochazi k poruseni referencni transparence, treba z duvodu efektivity).
Název: Re:Dědičnost dnes
Přispěvatel: JS 27. 01. 2017, 09:26:43
Těžko se k tomu hledá motivace. Monády řeší problém, který neexistuje.

Jesli znas treba funkci "flatMap" (napr. bere seznam, na kazdy prvek aplikuje funkci, ktera z nej dela seznam, a vysledny seznam spoji), tak vsechno, na co se da nejak aplikovat flatMap, je v podstate monada.

Nejde ani tak o to, ze monady resi nejaky konkretni problem; jsou spis popisem spolecnych vlastnosti mnoha ruznych veci (rika se tomu "abstrakce").

Na tohle snad monady nepotrebujete?

Viz vys - nepotrebujes vedet co jsou, ale monada se za tim najit da, konkretne monada funkci, co meni stav (stavova monada).
Název: Re:Dědičnost dnes
Přispěvatel: v 27. 01. 2017, 09:27:50
Mozna blba otazka, ale ja jsem myslel, ze kdyz knihovna v Haskellu nevyexportuje konstruktor, tak se k tomu nikdo krome knihovny nedostane. To neni zapouzdreni?

To mas pravdu, to me nenapadlo. To se samozrejme da brat jako zapouzdreni a je to v poradku.

Ale je tady jeden zasadni rozdil - v OOP je to skryvani nutne, protoze objekty jsou mutabilni, a neni mozne dovolit ostatnim s nimi zevne nakladat. Ale hodnoty predavane v FP jsou imutabilni, tudiz v podstate neni duvod je takto skryvat (vyjma snad situaci, kde uvnitr kodu fakticky dochazi k poruseni referencni transparence, treba z duvodu efektivity).
minimálně ještě jedna taková situace existuje (např. u Data.Map), kdy knihovní funkce předpokládají něco o hodnotách s nimiž pracují, tedy když typ umožňuje vytvořit (z nějakého pohledu) neplatnou hodnotu (a její kontrola není levná)
Název: Re:Dědičnost dnes
Přispěvatel: bob 27. 01. 2017, 09:40:44
Viz vys - nepotrebujes vedet co jsou, ale monada se za tim najit da, konkretne monada funkci, co meni stav (stavova monada).

Ja s tim souhlasim, ale o co mi slo. Ze se nekdo zepta  (zacatecnik v FP), jak tedy FP meni stavy, kdyz je vse immutable. A dostane odpoved, ktera je 100 % sravna, ale nejslozitejsi a pro novacka naprosto nevhodna. Chtel jsem rict, ze zakladni princip je mnohem jednodussi. Misto toho se dozvim, ze 18 lety chovanec jedlickova ustavu je chytrejsi nez ja a mel bych nechat IT...
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 10:48:50
V jiné diskuzi se řešila typová kontrola a vynucení implementace abstraktních metod. K tomu jsou metatřídy ideální.

Kurva, teď mě napadá: Nedalo by se úpravou metatřídy Objektu v Pythonu (či jak to má udělané) dodělat to chybějící zapouzdření???
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 10:52:36
Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80 (https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80). Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?

Java (https://projectlombok.org/features/experimental/ExtensionMethod.html) :)

Nene. To je (nejspíš) jen omrdávkou, jak rozšířit třídy final. Asi to šlohli z Ckanálu. Žádná z výše uvedených věcí se tím realizovat nedá.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 11:01:19
to je něco úplně jiného.

Je to stejný výsledek bez metatříd. Tohle jsou tedy jen rozšiřující metody, ukládání do DB dělá třeba Hibernate, třídy lze měnit za běhu JVM přes ClassLoader (https://stackoverflow.com/a/14317506/4538344). Nemá to tedy všechny schopnosti metatříd (třeba nejdou měnit již instancované objekty bez jejich znovuvytvoření, což jde přes ten Hibernate), ale ty zmíněné to umí.
...

Mluvíte o zcela něčem jiném. Mimoto ukládání (pouze!) stavů objektů přes Hibernate do RDB nemá s objektovou databází vůbec nic společného.
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 11:03:54
Viz vys - nepotrebujes vedet co jsou, ale monada se za tim najit da, konkretne monada funkci, co meni stav (stavova monada).

Ja s tim souhlasim, ale o co mi slo. Ze se nekdo zepta  (zacatecnik v FP), jak tedy FP meni stavy, kdyz je vse immutable. A dostane odpoved, ktera je 100 % sravna, ale nejslozitejsi a pro novacka naprosto nevhodna. Chtel jsem rict, ze zakladni princip je mnohem jednodussi. Misto toho se dozvim, ze 18 lety chovanec jedlickova ustavu je chytrejsi nez ja a mel bych nechat IT...

Přesně tak, navíc je ta odpověď pro někoho, kdo FP nezná, zavádějící. Ani stavová monáda totiž stav nemění v tom smyslu, že by upravovala nějakou mutable strukturu, jak by mohlo někoho, kdo FP nezná, napadnout.

Stavová monáda je jen (když to zjednoduším) sada funkcí a datových struktur, které jsou vhodné pro popis a kombinování immutable stavových automatů. Navíc  v jazycích se syntaktickou podporou pro monadické operace (haskell, scala) takové popisy vypadají skoro jako jako instrukce v imperativních programech (proto se taky monádám občas říká "programovatelný středník". I tady ale stále platí to, že při vykonávání programu se staré immutable stavy zahazují a vytvářejí se nové, jak tu někdo napsal přede mnou, a podle mě to opravdu nejlépe vystihuje, jak se v FP řeší stav.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 11:07:43
...Většina vědních oborů považuje jednoduchá řešení za elegantní a hledá právě jednoduchá řešení. SW inženýrství je výjimka. Vyžívá se v uměle složitých řešeních jednoduchých problémů. Proto je pro spoustu lidí jeho studium nepřístupné.

Nesouhlasím. V IT je mnoho krásných, geniálních, jednoduchých myšlenek, vhodným příkladem je zrovna původní, čisté OP. Klíčem je nepustit k jejich implementaci *uráky.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 11:45:28
A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

Tak jsem to pročetl... Je-li pan Armstrong spoluautorem Erlangu, je zarážející, že podstatu OOP naprosto, ale NAPROSTO nepochopil:

Objection 1: OOP oproti FP "data" a "funkce" spojuje z jednoduchého důvodu, a to, že data bez funkcí jsou k ničemu stejně tak jako funkce bez dat, přičemž funkce jsou vytvořeny pro daná data (to nevylučuje práci s obecnými daty jako v FP!). Myšlenka nutnosti nespojovat funkce a data jen z důvodu, že se jedná o jiné kategorie, je neopodstatněná (to ale neznamená, že to nejde).
Objection 2: Různé třídy (typy; či prototypy) pro různé časové údaje se používají v implementacích OOP naprosto běžně - tento bod je nadbytečný.
Objection 3: Všudypřítomné "typy" se realizují třídami či prototypy. Poslední věta fabuluje cosi o nutnosti dědění.
Objection 4: Objekty mají skryté stavy, ale nedávno mi tu pan Prýmek vysvětlil na Elixíru, že FP je má taky, akorát je jinak ukládá. Kde je potom rozdíl?

Závěr: Takhle teda ne.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 11:54:13
Tak zase abychom nekřivdili FP, každý, kdo používá seznam (v jakémkoliv jazyce), používá monády (i když to většina netuší). Jsou to prostě potvory všudypřítomné a myslím, že většinu lidí děsí jen ten termín, jinak je vesele používají všude možně. Navíc i v "čistém" FP se většinou používá syntaktický cukr, díky němuž kód vypadá celkem procedurálně.

A o tom to je: Problém nemusí vůbec být v monádách, ale ve vystižení jejich myšlenky. Měl jsem s tím problém na všech školách - jestliže přesně nevystihnul podstatu myšlenky (a to je přece smyslem), nefungovalo to.
Takže (nejen pro mě) by se hodilo uvést nějaký zdroj, který přesně vystihuje podstatu (jako neznalý jej nerozpoznám). Upozorňuju, že právě na Wikipedii jsou uvedeny příklady bez jakéhokoliv úvodu do syntaxe, takže jsou nečitelné. I na ten elixírový příklad jsem musel docela čumět, než jsem odhadnul, co by to asi tak mohlo dělat.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 11:57:11
V jiné diskuzi se řešila typová kontrola a vynucení implementace abstraktních metod. K tomu jsou metatřídy ideální.

Kurva, teď mě napadá: Nedalo by se úpravou metatřídy Objektu v Pythonu (či jak to má udělané) dodělat to chybějící zapouzdření???

Samozřejmě dalo, ale máš pak z toho ještě větší sračku než na začátku. Prostě Python nechat lopatám a i bez zapouzdření.

A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

Tak jsem to pročetl... Je-li pan Armstrong spoluautorem Erlangu, je zarážející, že podstatu OOP naprosto, ale NAPROSTO nepochopil:

Objection 1: OOP oproti FP "data" a "funkce" spojuje z jednoduchého důvodu, a to, že data bez funkcí jsou k ničemu stejně tak jako funkce bez dat, přičemž funkce jsou vytvořeny pro daná data (to nevylučuje práci s obecnými daty jako v FP!). Myšlenka nutnosti nespojovat funkce a data jen z důvodu, že se jedná o jiné kategorie, je neopodstatněná (to ale neznamená, že to nejde).
Objection 2: Různé třídy (typy; či prototypy) pro různé časové údaje se používají v implementacích OOP naprosto běžně - tento bod je nadbytečný.
Objection 3: Všudypřítomné "typy" se realizují třídami či prototypy. Poslední věta fabuluje cosi o nutnosti dědění.
Objection 4: Objekty mají skryté stavy, ale nedávno mi tu pan Prýmek vysvětlil na Elixíru, že FP je má taky, akorát je jinak ukládá. Kde je potom rozdíl?

Závěr: Takhle teda ne.

+1

Pán tomu prostě moc nerozumí, ale keců má plno :D
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 12:00:53
...Java hazi klacky pod nohy tim, ze chce mit vsude ty proklate objekty ;D.

Právě že nechce a právě že je to chybou, protože v okamžiku, kdy zavedete do jazyku nový koncept, počet interakcí s jinými koncepty násobně roste, takže např. v okamžiku, kdy necháte v rádobyobjektovém jazyku primitiva, musíte s nimi pracovat jinak než s objekty a ještě se vám objeví interakce primitivum-objekt a naopak!
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 12:05:11
Tak pokud monady povazujete za hazeni klacku pod nohy (monady jsou FP koncept), tak pak vam (se stejnou logikou) Java hazi klacky pod nohy tim, ze chce mit vsude ty proklate objekty ;D.

To je pravda. Bije to do očí, když se někdo snaží programovat v pythonu stejně jako v Javě a cpe vše do tříd. Některé problémy jsou z podstaty procedurální a OOP v nich k ničemu neposlouží.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 12:07:15
...jak už bylo napsáno, v javě se musí používat objekty jenom protože OOP

Co je to za debilní logiku?! Java vznikla jako implementace (nebo alespoň snaha) OOP. Jestli vás sere OOP, je tu dost jiných jazyků.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 12:12:43
...Java hazi klacky pod nohy tim, ze chce mit vsude ty proklate objekty ;D.

Právě že nechce a právě že je to chybou, protože v okamžiku, kdy zavedete do jazyku nový koncept, počet interakcí s jinými koncepty násobně roste, takže např. v okamžiku, kdy necháte v rádobyobjektovém jazyku primitiva, musíte s nimi pracovat jinak než s objekty a ještě se vám objeví interakce primitivum-objekt a naopak!

Nikdo ti je nenutí. Ale až se podíváš na rychlost, tak je možná ještě rád někde použiješ. Taková low-level optimalizace.

Tak pokud monady povazujete za hazeni klacku pod nohy (monady jsou FP koncept), tak pak vam (se stejnou logikou) Java hazi klacky pod nohy tim, ze chce mit vsude ty proklate objekty ;D.

To je pravda. Bije to do očí, když se někdo snaží programovat v pythonu stejně jako v Javě a cpe vše do tříd. Některé problémy jsou z podstaty procedurální a OOP v nich k ničemu neposlouží.

Ne, vyšší abstrakce rozhodně nic nezhorší.
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 12:25:05
Ne, vyšší abstrakce rozhodně nic nezhorší.

zbytečná abstrakce škodí.
Název: Re:Dědičnost dnes
Přispěvatel: v 27. 01. 2017, 12:26:13
...jak už bylo napsáno, v javě se musí používat objekty jenom protože OOP

Co je to za debilní logiku?! Java vznikla jako implementace (nebo alespoň snaha) OOP. Jestli vás sere OOP, je tu dost jiných jazyků.
to byla reakce na gll
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 12:34:32
jak už bylo napsáno, v javě se musí používat objekty jenom protože OOP

Ano musí, protože se ten jazyk snaží vnutit jeden styl. Programy jsou z podstaty procedurální. Všechna další omezení a abstrakce se hodí jen někde.
Název: Re:Dědičnost dnes
Přispěvatel: Doc9 27. 01. 2017, 12:48:29
Dědičnost/OOP je jen nástroj. Pokud někdo neumí nástroj používat nebo ho používá na něco, k čemu není určen, není to chyba nástroje. Takový soustruh, se kterým jdou dělat kouzla, taky neumí použít každý a ani s ním nejde vykopat díra v zemi. Ale ani jedno z toho není chyba soustruhu.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 12:51:06
Dědičnost/OOP je jen nástroj. Pokud někdo neumí nástroj používat nebo ho používá na něco, k čemu není určen, není to chyba nástroje. Takový soustruh, se kterým jdou dělat kouzla, taky neumí použít každý a ani s ním nejde vykopat díra v zemi. Ale ani jedno z toho není chyba soustruhu.

Na co se teda OOP vůbec nehodí a použil bys něco jiného?
Název: Re:Dědičnost dnes
Přispěvatel: zboj 27. 01. 2017, 12:53:59
Tak zase abychom nekřivdili FP, každý, kdo používá seznam (v jakémkoliv jazyce), používá monády (i když to většina netuší). Jsou to prostě potvory všudypřítomné a myslím, že většinu lidí děsí jen ten termín, jinak je vesele používají všude možně. Navíc i v "čistém" FP se většinou používá syntaktický cukr, díky němuž kód vypadá celkem procedurálně.

A o tom to je: Problém nemusí vůbec být v monádách, ale ve vystižení jejich myšlenky. Měl jsem s tím problém na všech školách - jestliže přesně nevystihnul podstatu myšlenky (a to je přece smyslem), nefungovalo to.
Takže (nejen pro mě) by se hodilo uvést nějaký zdroj, který přesně vystihuje podstatu (jako neznalý jej nerozpoznám). Upozorňuju, že právě na Wikipedii jsou uvedeny příklady bez jakéhokoliv úvodu do syntaxe, takže jsou nečitelné. I na ten elixírový příklad jsem musel docela čumět, než jsem odhadnul, co by to asi tak mohlo dělat.
U (různých typů) monád je problém, že krom pár abstraktních pravidel je nic na první pohled nespojuje, např. seznamy vs. kontinuace vs. maybe. Proto v nich asi tolik lidí plave a uniká jim sjednocující myšlenka. Ostatně já sám jsem znal monády dávno z matematiky, ale v kódu jsem je používal intuitivně. Až když mě rozmach FP donutil podívat se na něj blíže, došly mi všechny souvislosti. Možná je prostě lepší naučit se používat konkrétní typy monád a na abstraktní aparát za nimi se vykašlat, protože většina kodérů jej stejně nikdy v té abstraktní rovině nevyužije.
Název: Re:Dědičnost dnes
Přispěvatel: JS 27. 01. 2017, 12:56:15
Takže (nejen pro mě) by se hodilo uvést nějaký zdroj, který přesně vystihuje podstatu (jako neznalý jej nerozpoznám).

Myslim, ze by ti asi prospelo se to FP trochu naucit (treba Haskell), pak by jsi asi pochopil, odkud pan Armstrong prichazi (ja s nim celkem souhlasim). A take asi zjistil, jak jsou tve rychle usudky naivni. ;-)

Haskell neni tak tezky, ale je potreba trochu zapomenout, co vis o programovani a pristoupit k tomu s otevrenou hlavou. A je pravda, ze hodne tutorialu a tak vyzaduje trochu matematickeho mysleni, coz znamena trpelivost, pro nekoho, kdo v tom neni kovany treba ze skoly.
Název: Re:Dědičnost dnes
Přispěvatel: noef 27. 01. 2017, 12:59:42
Ale s monadami vas Haskell jako jazyk nenuti pracovat a rozhodne vam nehaze klacky pod nohy (spise naopak - do notace). Akorat pokud je  nepouzijete, tak je to vas problem - kod bude zbytecne neprehledny a napr. IO bude stejne nebezpecne jako OOP/imperativnich jazycich, takze z Haskellu neziskate zadnou vyhodu - mohli jste rovnou zustat u OOP a vyslo by vas to lepe, kdyz se snazite Haskell pouzivat jako Javu :D.

Haskell je dost prakticky zamereny (to me velmi prekvapilo, jsem ho vzdy ze skoly a clanku vnimal jako nejakou nepouzitelnou hracku) - umoznuje kvuli debugovani a optimalizacim hodne unsafe veci. Kdo chce prasit (=nepouzivat pri FP pristupu monady), ani Haskell mu nepomuze.

FP je o pristupu, ne jen o jazyku. Viz spory o tom, co je OOP - psat v Jave != praktikovat OOP. Neznam Elixir, ale myslim, ze nebyl ciste FP, takze bych se nedivil, kdyby tam byly mutable veci podobne jako ve Scale. Pokud vim, tak mutable veci jsou i v Haskellu a ten je casto oznacovan jako pure FP jazyk. Napr. v te Scale sam tvurce nezavrhuje mutable (at promenne nebo datove struktury), ale pouze za urcitych podminek (pouze lokalni, neprosakuji nikam ven).

... Možná je prostě lepší naučit se používat konkrétní typy monád a na abstraktní aparát za nimi se vykašlat, protože většina kodérů jej stejně nikdy v té abstraktní rovině nevyužije.

Ja si sice teorii precet, ale mam pocit, ze spis spadam do tech koderu :D. Ale svete div se, na to abych monady pouzival (jsem zelenac, nedavno jsem poprve pracoval se State monad) nepotrebuji skvele ovladat teorii za tim.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 13:04:06
Ja si sice teorii precet, ale mam pocit, ze spis spadam do tech koderu :D. Ale svete div se, na to abych monady pouzival (jsem zelenac, nedavno jsem poprve pracoval se State monad) nepotrebuji skvele ovladat teorii za tim.

Jenomže ta teorie se hezky zkouší na našich hloupých školách. Takže sice máš asi pocit, že jsi na to šel špatně, ale je to přesně naopak. Teorie ti je sama o sobě na nic... na titul to ale stačí. Proto dnes tituly už nemají žádnou cenu a ani na vývojáře/architekta ho mít nemusíš v podstatě nikde. Tam, kde ho chtějí, sedí hloupí lidé, tak je otázkou, jestli s nimi chceš dělat.
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 13:04:44
Dědičnost/OOP je jen nástroj. Pokud někdo neumí nástroj používat nebo ho používá na něco, k čemu není určen, není to chyba nástroje. Takový soustruh, se kterým jdou dělat kouzla, taky neumí použít každý a ani s ním nejde vykopat díra v zemi. Ale ani jedno z toho není chyba soustruhu.

Na co se teda OOP vůbec nehodí a použil bys něco jiného?

XMLHttpRequest vs jQuery.get
Název: Re:Dědičnost dnes
Přispěvatel: noef 27. 01. 2017, 13:32:03
...
Jenomže ta teorie se hezky zkouší na našich hloupých školách. Takže sice máš asi pocit, že jsi na to šel špatně, ale je to přesně naopak. Teorie ti je sama o sobě na nic... na titul to ale stačí. Proto dnes tituly už nemají žádnou cenu a ani na vývojáře/architekta ho mít nemusíš v podstatě nikde. Tam, kde ho chtějí, sedí hloupí lidé, tak je otázkou, jestli s nimi chceš dělat.

To me pripomina jednoho prednasejiciho na VUT FIT - rikaval nam, ze na bezne vyvijeni staci v pohode bakalar (na FITu je dost prakticky zamereny) a mel svatou pravdu. Ja si udelal i magistersky stupen a prestoze par predmetu se hodilo, tak bohuzel vetsina byla o tom se to naucit na zkousku a pak zapomenout. Nejhorsi a nejtezsi predmety byly ty, kde bylo hodne (nebo vyhradne) teorie a vyucujici se ani neobtezovali uvadet, kde (jestli vubec) se to v praxi pouziva. IMO to hodne lidi (vcetne me) dost demotivovalo. Pritom dost tech veci se opravdu v praxi pouziva, to jsem ale samozrejmne zjistil az mnohem pozdeji, kdyz jsem si ve volnem case procital wiki a ruzne novinky. Ta vyuka na nasich vysokych skolach me take neprijde optimalni.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 13:33:34
Právě že nechce a právě že je to chybou, protože v okamžiku, kdy zavedete do jazyku nový koncept, počet interakcí s jinými koncepty násobně roste, takže např. v okamžiku, kdy necháte v rádobyobjektovém jazyku primitiva, musíte s nimi pracovat jinak než s objekty a ještě se vám objeví interakce primitivum-objekt a naopak!

Nikdo ti je nenutí. Ale až se podíváš na rychlost, tak je možná ještě rád někde použiješ. Taková low-level optimalizace.

Máte recht. Akorát to značně komplikuje návrh jazyku i jeho implementaci.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 13:39:52
Myslim, ze by ti asi prospelo se to FP trochu naucit (treba Haskell), pak by jsi asi pochopil, odkud pan Armstrong prichazi (ja s nim celkem souhlasim). A take asi zjistil, jak jsou tve rychle usudky naivni. ;-)
...

Haskell, v pořádku. Každopádně já argumenty přiložil, pan Armstrong spíš spekulace a dojmy. Ale nakonec proč ne, jako já nerozumím FP, on nerozumí OOP.
Název: Re:Dědičnost dnes
Přispěvatel: SB 27. 01. 2017, 13:42:04
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 27. 01. 2017, 13:51:17
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 14:12:06
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

OOP je multiparadigmove zo svojej podstaty.
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 14:13:40
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

Podle mě je Smalltalk čistý OOP jazyk, a v praxi se používá velice příjemně.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 27. 01. 2017, 14:18:37
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

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).
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 14:22:08
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).

v pythonu, javascriptu a ruby je vše objekt. Znamená to, že tam nejsou primitivní typy?
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 14:27:28
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

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).

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++ .
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 14:41:54
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 ;-)
Název: Re:Dědičnost dnes
Přispěvatel: noef 27. 01. 2017, 14:44:43
...
v pythonu, javascriptu a ruby je vše objekt. Znamená to, že tam nejsou primitivní typy?

V JavaScriptu vse objekt neni, ma primitivni (https://developer.mozilla.org/en-US/docs/Glossary/Primitive) typy (akorat se s nim programator skoro nesetkava, protoze probiha "auto-boxing").
Název: Re:Dědičnost dnes
Přispěvatel: zboj 27. 01. 2017, 14:53:32
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 ;-)
Čekal jsem, kdo na tu krávovinu zareaguje :)
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 15:04:29
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 ;-)
Čekal jsem, kdo na tu krávovinu zareaguje :)

Ok, berem spat, v smalltalku sa selectory, ekvivalenty metod nepouzivaju. Ani objekty sa nepredavaju cez selectory ako "spravy".  Ono v tom smalltalku proste je to cele magicke a objekty sa rozpravaju recou starych kuzelnikov.
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 15:37:33
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 ;-)
Čekal jsem, kdo na tu krávovinu zareaguje :)

Ok, berem spat, v smalltalku sa selectory, ekvivalenty metod nepouzivaju. Ani objekty sa nepredavaju cez selectory ako "spravy".  Ono v tom smalltalku proste je to cele magicke a objekty sa rozpravaju recou starych kuzelnikov.

Ty si nedáš říci .. no tak mi naprogramuj následující tři prográmky (ve smalltalku téměř one-linery) v C++:

1) Zeptej se uživatele na string, a pošli objektu Foo zprávu (nebo v C++ terminologii zavolej na objektu Foo metodu), která se jmenuje stejně jako zadaný String. Vypiš uživateli výsledek volání, pokud Foo danou metodu nemá, vypiš uživateli, že to neumí..

2) Za běhu zjisti, jaké zprávy Foo umí přijímat

3) Stejně jako 1, ale pokud Foo zprávu neumí, za běhu přidej implementaci, která vrátí String "Jsem tu nová", a opakuj volání zprávy na Foo

4) (to už se netýká zpráv, ale jen tak pro zajímavost): Za běhu zjisti, jaké třídy je Foo instance, a jaké další podtřídy tato třída má.

Pod řešení mi můžeš napsat, že zprávy v C++ a ve Smalltalku jsou to same.
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 15:54:24
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 ;-)
Čekal jsem, kdo na tu krávovinu zareaguje :)

Ok, berem spat, v smalltalku sa selectory, ekvivalenty metod nepouzivaju. Ani objekty sa nepredavaju cez selectory ako "spravy".  Ono v tom smalltalku proste je to cele magicke a objekty sa rozpravaju recou starych kuzelnikov.

Ty si nedáš říci .. no tak mi naprogramuj následující tři prográmky (ve smalltalku téměř one-linery) v C++:

1) Zeptej se uživatele na string, a pošli objektu Foo zprávu (nebo v C++ terminologii zavolej na objektu Foo metodu), která se jmenuje stejně jako zadaný String. Vypiš uživateli výsledek volání, pokud Foo danou metodu nemá, vypiš uživateli, že to neumí..

2) Za běhu zjisti, jaké zprávy Foo umí přijímat

3) Stejně jako 1, ale pokud Foo zprávu neumí, za běhu přidej implementaci, která vrátí String "Jsem tu nová", a opakuj volání zprávy na Foo

4) (to už se netýká zpráv, ale jen tak pro zajímavost): Za běhu zjisti, jaké třídy je Foo instance, a jaké další podtřídy tato třída má.

Pod řešení mi můžeš napsat, že zprávy v C++ a ve Smalltalku jsou to same.

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.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 27. 01. 2017, 16:00:27
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 ;-)
Čekal jsem, kdo na tu krávovinu zareaguje :)

Ok, berem spat, v smalltalku sa selectory, ekvivalenty metod nepouzivaju. Ani objekty sa nepredavaju cez selectory ako "spravy".  Ono v tom smalltalku proste je to cele magicke a objekty sa rozpravaju recou starych kuzelnikov.

Ty si nedáš říci .. no tak mi naprogramuj následující tři prográmky (ve smalltalku téměř one-linery) v C++:

1) Zeptej se uživatele na string, a pošli objektu Foo zprávu (nebo v C++ terminologii zavolej na objektu Foo metodu), která se jmenuje stejně jako zadaný String. Vypiš uživateli výsledek volání, pokud Foo danou metodu nemá, vypiš uživateli, že to neumí..

2) Za běhu zjisti, jaké zprávy Foo umí přijímat

3) Stejně jako 1, ale pokud Foo zprávu neumí, za běhu přidej implementaci, která vrátí String "Jsem tu nová", a opakuj volání zprávy na Foo

4) (to už se netýká zpráv, ale jen tak pro zajímavost): Za běhu zjisti, jaké třídy je Foo instance, a jaké další podtřídy tato třída má.

Pod řešení mi můžeš napsat, že zprávy v C++ a ve Smalltalku jsou to same.
Jde o jednoho z místních trolů, takže bych radil nereagovat.
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 16:02:40
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 ;-)
Čekal jsem, kdo na tu krávovinu zareaguje :)

Ok, berem spat, v smalltalku sa selectory, ekvivalenty metod nepouzivaju. Ani objekty sa nepredavaju cez selectory ako "spravy".  Ono v tom smalltalku proste je to cele magicke a objekty sa rozpravaju recou starych kuzelnikov.

Ty si nedáš říci .. no tak mi naprogramuj následující tři prográmky (ve smalltalku téměř one-linery) v C++:

1) Zeptej se uživatele na string, a pošli objektu Foo zprávu (nebo v C++ terminologii zavolej na objektu Foo metodu), která se jmenuje stejně jako zadaný String. Vypiš uživateli výsledek volání, pokud Foo danou metodu nemá, vypiš uživateli, že to neumí..

2) Za běhu zjisti, jaké zprávy Foo umí přijímat

3) Stejně jako 1, ale pokud Foo zprávu neumí, za běhu přidej implementaci, která vrátí String "Jsem tu nová", a opakuj volání zprávy na Foo

4) (to už se netýká zpráv, ale jen tak pro zajímavost): Za běhu zjisti, jaké třídy je Foo instance, a jaké další podtřídy tato třída má.

Pod řešení mi můžeš napsat, že zprávy v C++ a ve Smalltalku jsou to same.
Jde o jednoho z místních trolů, takže bych radil nereagovat.

Preco, mna tieto pseudoodborne diskusie o tom co je "prave" OOP celkom bavia.
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 16:07:38
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.

Repostujem, aby nezaniklo
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 16:08:14
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.

Aha, tak jestli jsem si měl z tvého příspěvku odnést, že posílání zpráv ve smalltalku není objektová magie, tak to pardon, díky moc za hluboký vhled, to mi otočilo světla...
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 16:12:34
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.

Aha, tak jestli jsem si měl z tvého příspěvku odnést, že posílání zpráv ve smalltalku není objektová magie, tak to pardon, díky moc za hluboký vhled, to mi otočilo světla...

Len tu bolo posielanie sprav tak prezentovane. Ze ostatne OOP jazyky to nemaju. Tak som vybral ako priklad ten najhorsi OOP jazyk.
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 16:14:52

Aha, tak jestli jsem si měl z tvého příspěvku odnést, že posílání zpráv ve smalltalku není objektová magie, tak to pardon, díky moc za hluboký vhled, to mi otočilo světla...

Len tu bolo posielanie sprav tak prezentovane. Ze ostatne OOP jazyky to nemaju. Tak som vybral ako priklad ten najhorsi OOP jazyk.

Kde to tak bylo prezentované? Rozhodně ne v příspěvku, na který jsi reagoval.
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 16:17:25
...A take asi zjistil, jak jsou tve rychle usudky naivni. ;-) ...

Jo, a na ty rychlé úsudky pozor, čistému OP se věnuju mnoho let.
"Čisté" OOP je tak trochu iluze, ne? Aspoň v praxi...

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).
Název: Re:Dědičnost dnes
Přispěvatel: ava 27. 01. 2017, 16:22:42
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 16:27:35
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.

Ja som z vas zmateny tiez.  Reflexiu proste nazyvam reflexiou. A ostatne, netusim o com hovorite.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 16:31:41
Hlavně asi těžko budu volat metodu dynamicky :D Co bych z toho měl? Komu tím jako prospěju? Co na to architekt u vás?
Název: Re:Dědičnost dnes
Přispěvatel: zboj 27. 01. 2017, 16:40:09
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 27. 01. 2017, 18:14:04
Hlavně asi těžko budu volat metodu dynamicky :D Co bych z toho měl? Komu tím jako prospěju? Co na to architekt u vás?
Proxy
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 18:17:35
Proxy čeho? Já teda chci přesně vědět, co budu volat. Případně to udělám reflexí... neudělám! :D
Název: Re:Dědičnost dnes
Přispěvatel: čumil 27. 01. 2017, 18:18:28
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Virtualky jsou jen chaba nahrada toho co máš třeba v js.
Jakejkoli typovej system nejde dohromady s oop, pak vznikaj jenom kompromisy..
Název: Re:Dědičnost dnes
Přispěvatel: čumil 27. 01. 2017, 18:19:59
Proxy čeho? Já teda chci přesně vědět, co budu volat. Případně to udělám reflexí... neudělám! :D
Klidně proxy proxy. Podle chuti osol.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 18:25:56
Proxy čeho? Já teda chci přesně vědět, co budu volat. Případně to udělám reflexí... neudělám! :D
Klidně proxy proxy. Podle chuti osol.

Proxy se dělá přes rozhraní, takže asi nemám problém s tím, co mám volat :D Jako chápu, že musí být pro frikulíny mít každou část nezávislou a přidávat věci podle potřeby, ale takhle se nevyvíjí.
Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 18:57:36
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Virtualky jsou jen chaba nahrada toho co máš třeba v js.
Jakejkoli typovej system nejde dohromady s oop, pak vznikaj jenom kompromisy..

OOP nie je o tom, ci sa pouziva staticke, alebo dynamicke typovanie. Oboje ma svoje nevyhody a vyhody.
Su tam podobne problemy ako v inych paradigmach so statickym a dynamickym typovanim.  Staticke typovanie ide dobre dokopy s OOP.



Název: Re:Dědičnost dnes
Přispěvatel: balki 27. 01. 2017, 19:00:08
Dodam, ze to, ze je smalltalk dynamicky typovany, je sposobene tym, ze sa allen key inspiroval lisp-om. Ak by sa inspiroval algolom, vyzeralo by to zasa inak.
Název: Re:Dědičnost dnes
Přispěvatel: ferren 27. 01. 2017, 19:24:40
ten uvadeny ukol, pokud by nekdo takoveto predavani zprav v c++ fakt chtel, tak samozrejme nastroje ma ( nenapada me moc duvidu proc to delat ale). jen si ten msg handler musis napsat plus u metod pouzit preprocesor a dynamicky generovany source. viz treba zdrojaky unreal enginu, kde se to pouziva na mix c++ a node graph based scriptingu

jinak je to nesmyslne zadani, nezadava problem k reseni ale za to podsouva implementaci.
nestrane zadani ukolu 1 by pak napr znelo nejak jako proved funkcionalitu dle zadaneho vstupu, no a pak bys od ceckare dostal prachsprostej switch/case/default ;-)
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 19:52:03
jinak je to nesmyslne zadani, nezadava problem k reseni ale za to podsouva implementaci.
nestrane zadani ukolu 1 by pak napr znelo nejak jako proved funkcionalitu dle zadaneho vstupu, no a pak bys od ceckare dostal prachsprostej switch/case/default ;-)

má to využití hlavně při interaktivním používání v různých shellech a při testování programu během vývoje. Podobné featury mohou podstatně urychlit vývoj, i pokud se ve finálním kódu nepoužijí. Zrovna u her to asi moc nevyužijete, ale třeba efektivní práci s webovými API nebo s databází si ve statickém jazyce moc představit nedokážu.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 27. 01. 2017, 19:56:14
ten uvadeny ukol, pokud by nekdo takoveto predavani zprav v c++ fakt chtel, tak samozrejme nastroje ma ( nenapada me moc duvidu proc to delat ale). jen si ten msg handler musis napsat plus u metod pouzit preprocesor a dynamicky generovany source. viz treba zdrojaky unreal enginu, kde se to pouziva na mix c++ a node graph based scriptingu

jinak je to nesmyslne zadani, nezadava problem k reseni ale za to podsouva implementaci.
nestrane zadani ukolu 1 by pak napr znelo nejak jako proved funkcionalitu dle zadaneho vstupu, no a pak bys od ceckare dostal prachsprostej switch/case/default ;-)

Řídící objekty, agregační funkce, zástupné hodnoty, distribuované objekty, objektové vazby v MVC... Tam všude to, na co ten úkol mířil,  dost výrazně ulehčuje práci.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 27. 01. 2017, 19:56:20
Kdyby to urychlovalo vývoj, tak se to používá. To je asi jako že ženy jsou stejně schopné jako muži, jen dostávají méně. Kdyby byly tak úžasné, tak jsou všude, ne?
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 20:00:50
Kdyby to urychlovalo vývoj, tak se to používá. To je asi jako že ženy jsou stejně schopné jako muži, jen dostávají méně. Kdyby byly tak úžasné, tak jsou všude, ne?

Musí se to umět používat a dodržovat určitou disciplínu. Když v tom budeš programovat stejně jako v Javě, tak to tvou produktivitu naopak sníží.
Název: Re:Dědičnost dnes
Přispěvatel: ferren 27. 01. 2017, 20:07:07
jinak je to nesmyslne zadani, nezadava problem k reseni ale za to podsouva implementaci.
nestrane zadani ukolu 1 by pak napr znelo nejak jako proved funkcionalitu dle zadaneho vstupu, no a pak bys od ceckare dostal prachsprostej switch/case/default ;-)

má to využití hlavně při interaktivním používání v různých shellech a při testování programu během vývoje. Podobné featury mohou podstatně urychlit vývoj, i pokud se ve finálním kódu nepoužijí. Zrovna u her to asi moc nevyužijete, ale třeba efektivní práci s webovými API nebo s databází si ve statickém jazyce moc představit nedokážu.

na to pak staci metoda uvadena u unreal enginu. z kazde metody mas pak napr krabicku s porty, co si pak muzes libovolne chainovat v gui. nebo v tvem pripade treba shellu.
jinak samozrejme c++ ma bindingy temer na vsechny jazyky, tak bych treba na to pouzil Lua uvnitr c++ treba. nebo treba lisp/scheme kde jsem si msg passing na skole uzil do sytosti:-)
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 20:13:26
jinak je to nesmyslne zadani, nezadava problem k reseni ale za to podsouva implementaci.
nestrane zadani ukolu 1 by pak napr znelo nejak jako proved funkcionalitu dle zadaneho vstupu, no a pak bys od ceckare dostal prachsprostej switch/case/default ;-)

má to využití hlavně při interaktivním používání v různých shellech a při testování programu během vývoje. Podobné featury mohou podstatně urychlit vývoj, i pokud se ve finálním kódu nepoužijí. Zrovna u her to asi moc nevyužijete, ale třeba efektivní práci s webovými API nebo s databází si ve statickém jazyce moc představit nedokážu.

na to pak staci metoda uvadena u unreal enginu. z kazde metody mas pak napr krabicku s porty, co si pak muzes libovolne chainovat v gui. nebo v tvem pripade treba shellu.
jinak samozrejme c++ ma bindingy temer na vsechny jazyky, tak bych treba na to pouzil Lua uvnitr c++ treba. nebo treba lisp/scheme kde jsem si msg passing na skole uzil do sytosti:-)

Nebo naopak můžete z aplikace ve skriptovacím jazyce volat C/C++ funkce pomocí FFI. To vyjde téměř nastejno. Asi se shodneme, že každý jazyk se hodí na něco jiného.
Název: Re:Dědičnost dnes
Přispěvatel: ferren 27. 01. 2017, 20:19:54
jinak je to nesmyslne zadani, nezadava problem k reseni ale za to podsouva implementaci.
nestrane zadani ukolu 1 by pak napr znelo nejak jako proved funkcionalitu dle zadaneho vstupu, no a pak bys od ceckare dostal prachsprostej switch/case/default ;-)

má to využití hlavně při interaktivním používání v různých shellech a při testování programu během vývoje. Podobné featury mohou podstatně urychlit vývoj, i pokud se ve finálním kódu nepoužijí. Zrovna u her to asi moc nevyužijete, ale třeba efektivní práci s webovými API nebo s databází si ve statickém jazyce moc představit nedokážu.

na to pak staci metoda uvadena u unreal enginu. z kazde metody mas pak napr krabicku s porty, co si pak muzes libovolne chainovat v gui. nebo v tvem pripade treba shellu.
jinak samozrejme c++ ma bindingy temer na vsechny jazyky, tak bych treba na to pouzil Lua uvnitr c++ treba. nebo treba lisp/scheme kde jsem si msg passing na skole uzil do sytosti:-)

Nebo naopak můžete z aplikace ve skriptovacím jazyce volat C/C++ funkce pomocí FFI. To vyjde téměř nastejno. Asi se shodneme, že každý jazyk se hodí na něco jiného.

vsak jo, ja jen reagoval na zadani "napis mi neco nemecky, aby to znelo francouzky"
Název: Re:Dědičnost dnes
Přispěvatel: gll 27. 01. 2017, 20:53:06
vsak jo, ja jen reagoval na zadani "napis mi neco nemecky, aby to znelo francouzky"

Rozumím. Já se snažil říct, že nezáleží jen na problému, který řešíte, ale i postupech, které používáte. Ty body, které jmenoval zboj nemusí být součástí finálního řešení, ale mohou vám usnadnit jeho tvorbu.
Název: Re:Dědičnost dnes
Přispěvatel: v 27. 01. 2017, 20:53:52
napis mi neco nemecky, aby to znelo francouzky
Flammekueche
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 27. 01. 2017, 22:52:18
vsak jo, ja jen reagoval na zadani "napis mi neco nemecky, aby to znelo francouzky"

Tady přece nejde o to, že by něco nějak "říci" nešlo. Bavíme se o turingovsky úplných jazycích, což znamená, že v každém takovém jde "říci" všechno. Problém je v tom, jak složitě se ta věc v různých jazycích dá napsat. Zatímco v jednom je to na jeden, dva řádky, v jiném to může být na půl stránky. Zatímco Angličan řekne "he was writing", Čech řekne "psal". U jiných věcí to zas bude třeba naopak.
Takže když mi jazyk nabízí prostředky pro snadné zachycení zprávy, zjištění, který objekt dané zprávě rozumí, její přesměrování apod., tak se mi řada věcí dost zjednoduší. Např. kdybych psal nějaký vektorový kreslící program, tak zobrazení možných manipulací třeba po rightclicku bude naprosto triviální záležitost, fungující univerzálně pro všechny objekty. Takže mi to ušetří spoustu psaní a tím i spoustu potenciálních chyb a tím i spoustu času a tím to zvýší produktivitu mé práce.

Mám pocit, že lidé tohle kouzlení se zprávami, (multi)proxy, záchytnými objekty, budoucími objekty, pojmenovanými atributy atd. považují buď za nějaký šamanismus, nebo něco nečistého. Ale právě u takových věcí teprve naplno vyniknou výhody OOP oproti klasickému strukturovanému přístupu. Většina "objektových" programů, které mi prošly pod rukama, ve skutečnosti vůbec objektové nebyly. Akorát tam autoři nacpali procedury a data do tříd, ale žádnou výhodu to nepřineslo. Kdyby to bývali napsali klasicky strukturovaně, vyšlo by to nastejno s tím, že by to bylo o něco kratší o ten objektový syntaktický cukr. A je pravda, že "objektové" jazyky jako je C++ tomuto "kouzlení" vůbec nijak nepomáhají, narozdíl např. od Objective C.
Název: Re:Dědičnost dnes
Přispěvatel: Polymath 27. 01. 2017, 23:27:47
napis mi neco nemecky, aby to znelo francouzky
Flammekueche
To neexistuje.
Název: Re:Dědičnost dnes
Přispěvatel: balki 28. 01. 2017, 00:02:22
napis mi neco nemecky, aby to znelo francouzky
Flammekueche
To neexistuje.

Orangensahne creme
Název: Re:Dědičnost dnes
Přispěvatel: JS 28. 01. 2017, 08:45:36
Haskell, v pořádku. Každopádně já argumenty přiložil, pan Armstrong spíš spekulace a dojmy. Ale nakonec proč ne, jako já nerozumím FP, on nerozumí OOP.

Jak vis, ze nerozumi OOP? Zato vime, ze ty neznas FP.. Me prijde, ze tak trochu popiras, ze by sly veci delat lepe.

Ja asi neznam nikoho (slavnejsiho) kdo zna oboji, a netvrdil by, ze FP je minimalne stejne dobre jako OOP, a pokud ano, tak jsou to casto Smalltalkiste (mozna Gilad Bracha).

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Ono ostatne i existence mnoha "design patterns" naznacuje, ze takova ta originalni predstava OOP, ze lze pomoci trid modelovat domenove objekty, tak docela nevysla.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 28. 01. 2017, 09:54:54
 :o
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Virtualky jsou jen chaba nahrada toho co máš třeba v js.
Jakejkoli typovej system nejde dohromady s oop, pak vznikaj jenom kompromisy..

OOP nie je o tom, ci sa pouziva staticke, alebo dynamicke typovanie. Oboje ma svoje nevyhody a vyhody.
Su tam podobne problemy ako v inych paradigmach so statickym a dynamickym typovanim.  Staticke typovanie ide dobre dokopy s OOP.
Je :D přesně o tom oop je, v opačném případě jsi ho těžce nepochopil.
Konec konců, říkám jen to co říká Alan :)
Název: Re:Dědičnost dnes
Přispěvatel: balki 28. 01. 2017, 11:05:12
:o
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Virtualky jsou jen chaba nahrada toho co máš třeba v js.
Jakejkoli typovej system nejde dohromady s oop, pak vznikaj jenom kompromisy..

OOP nie je o tom, ci sa pouziva staticke, alebo dynamicke typovanie. Oboje ma svoje nevyhody a vyhody.
Su tam podobne problemy ako v inych paradigmach so statickym a dynamickym typovanim.  Staticke typovanie ide dobre dokopy s OOP.
Je :D přesně o tom oop je, v opačném případě jsi ho těžce nepochopil.
Konec konců, říkám jen to co říká Alan :)

Citaciu prosim. Pokial viem, Alan Key (Dufam, ze som ho zasa neskomolil), dynamicke typovanie preferuje, ale nezavrhuje staticke typovanie.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 28. 01. 2017, 11:39:51
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Ono ostatne i existence mnoha "design patterns" naznacuje, ze takova ta originalni predstava OOP, ze lze pomoci trid modelovat domenove objekty, tak docela nevysla.

To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 28. 01. 2017, 11:44:35
Alan Key (Dufam, ze som ho zasa neskomolil)

Bohužel, ani napodruhé ti to nevyšlo.  :)
Název: Re:Dědičnost dnes
Přispěvatel: balki 28. 01. 2017, 12:20:23
Alan Key (Dufam, ze som ho zasa neskomolil)

Bohužel, ani napodruhé ti to nevyšlo.  :)

Do krista, zasa. Na skole som musel mat na neho latexove makro :)
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 12:33:36
Tady jsme si spíš nerozuměli, předpokládal jsem, že se porovnává funkce z imperativních jazyků (tj. v podstatě procedura) s objektovým posíláním. Funkcionální funkci (tj. v podstatě matematickou funkci) jsem na mysli neměl.
Ok.

To vypadá dobře. I když implementovat asynchronní v synchronním jde tady.
Jde, ale je to míň praktické - musím pro každé volání rezervovat thread/process. Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".

3. odeslání zprávy nemusí nic "vracet" nebo může "vracet" víc hodnot postupně
...
To už je věcí implementace na druhé straně, to bych tu nerozebíral. Ale vypadá to zajímavě.
Chtěl jsem tím říct, že (asynchronní) posílání zpráv je "obecnější" než volání funkce - v takovém spíš sémantickém než technickém smyslu, protože samozřejmě funkci taky můžu předat callback, který pak bude volat znovu a znovu...


Monády mi stačila, jen jsem je nestihl prostudovat.
Monády jsou v principu celkem jednoduché, ale bývá problém je vysvětlit/pochopit, proto jsem dal příklad, který je myslím každému programátorovi jasný na první pohled.

Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable.
Tady nebezpečně motáš pojmy. Mutabilita se týká dat. Co je "mutabilita modulu", to bysme si museli nějak zadefinovat, jinak to bude plácání o koze a o voze :)

Tzn. tvrzení, že v FP je vše immutable, asi nebude pravdivé. Dále předpokládám, že jsou hodnoty při volání funkce či posílání zprávy předávány odkazem, jinak by celé toto čarování nemělo smysl.
V různých jazycích je to různě. V tom Elixiru, ve kterém příklad byl, platí, že jakmile mám jednou nějaká data, tak je už nikdy nemůžu změnit. Čili tam vůbec nedává smysl mluvit o volání odkazem nebo hodnotou - je to úplně to samé, je mi úplně jedno, jak je to implementované, protože třeba asoc. pole {'a' => 1} bude už navždy mít jenom jeden klíč, nikdo tam nijak nemůže přidat druhý. Čili to pole můžu úplně klidně předávat kamkoli, do kolika vláken chci a nemusím se bát, že by mi ho nějaké jiné vlákno neočekávaně změnilo pod rukama. Pokud někdo chce do pole přidat další klíč, vznikne mu nové pole, které s tím starým nemá nic společného (a navíc protože původní už nikdo nemůže změnit, můžou ty dvě pole úplně klidně a bezpečně sdílet data - ale to už je otázka implementace, která mě jako uživatele jazyka nezajímá).

Nicméně Elixir (a jeho "podvozek" Erlang) negarantují to, že když dvakrát zavolám tu stejnou funkci se stejnými parametry, dostanu stajný výsledek. Čili k tomu stavu můžu přistupovat přes funkci (která obalí posílání zpráv) a dostanu pokaždé stav, který je aktuální v daném okamžiku.

Ve víc striktních jazycích (Haskell, Elm, ...) tohle neplatí. Tam ta garance je ještě tvrdší než v Elixiru. Proto jsem říkal, že v různých je zycích je "míra imutability" (a tím i míra platných garancí) různá.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 28. 01. 2017, 12:44:02
To vypadá dobře. I když implementovat asynchronní v synchronním jde tady.
Jde, ale je to míň praktické - musím pro každé volání rezervovat thread/process. Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 12:44:28
Tail-call je o optimizaci návratu po návratu. V uvedeném příkladu zavolání loop(něco) se odnikud nevrací, naopak buďto je to rekurze a zásobník roste, nebo je to skok a stejně je třeba vytvořit nový kontext, ale starý je zahoditelný.
Ano, starý kontext se zahazuje v případě, že dojde ke změně stavu. Tím se to liší od těch monád, kde jde spíš o f(g(h(x))).
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 12:52:36
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.
Myslel jsem prostředky toho jazyka samotného. Pokud mám fci, která blokuje, třeba http_get_content(uri), tak programátorskými prostředky (uvnitř jazyka) z ní asynchronní neudělám jinak než (pseudokód):
Kód: [Vybrat]
start_thread(fun(){
  content = http_get_content(uri)
  do_something_with(content)
})
this_is_not_blocked(x,y,z)

Maximálně bych mohl mít v jazyce nějakou spešl konstrukci, která se vnitřně přeloží nějak speciálně, třeba samostatná vlákna runtime simuluje v rámci jednoho vlákna, ale to je z louže pod okap... Ta situace s asynchronností jako defaultem mi prostě přijde lepší (YMMV).
Název: Re:Dědičnost dnes
Přispěvatel: zboj 28. 01. 2017, 12:56:42
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.
Myslel jsem prostředky toho jazyka samotného. Pokud mám fci, která blokuje, třeba http_get_content(uri), tak programátorskými prostředky (uvnitř jazyka) z ní asynchronní neudělám jinak než (pseudokód):
Kód: [Vybrat]
start_thread(fun(){
  content = http_get_content(uri)
  do_something_with(content)
})
this_is_not_blocked(x,y,z)

Maximálně bych mohl mít v jazyce nějakou spešl konstrukci, která se vnitřně přeloží nějak speciálně, třeba samostatná vlákna runtime simuluje v rámci jednoho vlákna, ale to je z louže pod okap... Ta situace s asynchronností jako defaultem mi prostě přijde lepší (YMMV).
Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 12:58:32
Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).
Souhlas, dík za doplnění. Nic to ale nemění na tom, že:
Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".
Název: Re:Dědičnost dnes
Přispěvatel: zboj 28. 01. 2017, 13:12:49
Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).
Souhlas, dík za doplnění. Nic to ale nemění na tom, že:
Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".
To mi přijde trochu subjektivní, protože i blokování je věc runtimu, ale pravda je, že příslušný kód je trochu přímočařejší. I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 13:14:17
Nevim, mě na tom nic složitého nepřijde a dá se to snadno pochopit i bez znalostí tuny teorie. IMHO to spousta lidí používá v praxi i mimo FP aniž by znali pojem monáda (což bude asi největší problém, že neznají pojem a ne myšlenku). Např. optional template v boostu.
Už jsme se tady o tom bavili spoustukrát, tak to nechci rozpitvávat, ale jednu poznámku si dovolím (opakovaně): koncept monády je obecný koncept, který má mnoho instancí. "Chápat monády" znamená chápat ten obecný koncept, chápat, že jeho jednotlivé instance mají nějaké společné vlastnosti, že je to z nějakého pohledu totéž. Např. že list, maybe a future mají stejný princip. A to je úplně něco jiného než umět používat list nebo future.

To, cos řekl, je úplně to samé, jako bys řekl:
Citace
Spousta lidí používá v praxi sčítání aniž by znali pojem monoid.
...jistě. Protože chápat sčítání a chápad monoid jsou dvě dost rozdílné věci.

Moc se mi líbilo, když Evan Czaplicki (autor jazyka Elm) říkal (volně):
Citace
- Nemluvme o monádách! Vůbec ten pojem nepoužívejme, mluvme o x,y,z...
- Ale jak pak pojmenujeme jejich společné vlastnosti?
- Jejich společné vlastnosti samozřejmě jsou "monáda", my o nich ale nepotřebujeme mluvit.

Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 13:19:46
I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.
Jo, channel tam vlastně sehraje úlohu toho "asynchronizačního bufferu". Pořád je to ale to "něco navíc", co musím někde vytvořit, má to (aspoň teoreticky) nějakou režii, nějak to komplikuje kód. Přijde mi daleko přímočařejší kód, který když nechci, aby blokoval, tak nedělám nic, když chci, aby blokoval, tak prostě čekám na místě, dokud nedojde k události. Vytvářet thread/rutinu/channel kvůli jednomu volání je prostě (pocitově) pro mě míň estetické ;)

...ale to jsme se dostali do zbytečných detailů, myslím, že si rozumíme a nejsme v žádném sporu :)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 28. 01. 2017, 13:25:07
I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.
Jo, channel tam vlastně sehraje úlohu toho "asynchronizačního bufferu". Pořád je to ale to "něco navíc", co musím někde vytvořit, má to (aspoň teoreticky) nějakou režii, nějak to komplikuje kód. Přijde mi daleko přímočařejší kód, který když nechci, aby blokoval, tak nedělám nic, když chci, aby blokoval, tak prostě čekám na místě, dokud nedojde k události. Vytvářet thread/rutinu/channel kvůli jednomu volání je prostě (pocitově) pro mě míň estetické ;)

...ale to jsme se dostali do zbytečných detailů, myslím, že si rozumíme a nejsme v žádném sporu :)
Možná mi něco nedocvaklo, ale blokování asynchronního volání (resp. čekání) má taky režii, potřebuju třeba semafor nebo tak něco, ne? Jinak bych to asi fakt ukončil, v konečném důsledku ten zápis v obou případech závisí na konkrétním jazyce a příslušném běhovém prostředí.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 13:26:29
Erlang je v některých ohledech přísnější než Elixir. Elixir má narozdíl od Erlangu mutable proměnné. Což považuji za výhodu.
Ne! To je jenom syntaktický cukr, aby člověk nemusel psát
Kód: [Vybrat]
v = 1
v1 = v+2
v2 = v1 + 3
...což strašně komplikuje přepisování kódu.

Elixir a Erlang se v tomhle liší jenom syntaxí, ale podvozek je úplně stejný.

Viz http://stackoverflow.com/a/30000838/3150343
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 13:29:50
Možná mi něco nedocvaklo, ale blokování asynchronního volání (resp. čekání) má taky režii, potřebuju třeba semafor nebo tak něco, ne?
V implementaci jo. Ale v jazyce můžu mít třeba jenom to zmíněné
Kód: [Vybrat]
receive do
  :message_i_am_waiting_for -> :ok
end
...což mi přijde parádně čitelné - na první pohled vidím "tady čekám na zprávu".
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 14:02:35
Neznam Elixir, ale myslim, ze nebyl ciste FP, takze bych se nedivil, kdyby tam byly mutable veci podobne jako ve Scale.
Ne, tak jako ve Scale ne, ani trochu.

Elixir je taková "nadstavba" nad Erlangem, tady z těch základních věcí tam platí všechno, co v Erlangu:

1. data jsou naprosto striktně immutable, nejde je měnit vůbec nijak (neexistuje ani žádný hack/pragma/meta/výjimka, která by to umožnila)

2. funkce můžou mít vedlejší efekty => není garantovaná referenční transparentnost

3. primárním cílem Erlangu/Elixiru není funkcionální programování, ale "concurrent programming". FP je tam jenom do té míry, do které dává smysl jako podvozek pro CP. Proto Elixir ani Erlang nejsou "čisté" funkcionální jazyky, spíš pragmatické. Ale zase to není takový ten kočkopes jako Scala, kde si můžu vybrat, že v téhle části kódu použiju X a v jiné Y, tady budu mutabilní a tady ne. To v Elixiru není.

4. základním stavebním blokem Erlangu jsou procesy, které komunikují pomocí zpráv a nemůžou sdílet stav jinak než přes databázi (protože bod 1).

5. Erlang a (trochu míň) Elixir mají kořeny v Prologu,  ne v FP. Proto je tam z FP jenom to, co pragmaticky dávalo smysl pro celek toho jazyka (a vybrali to velmi dobře - ten jazyk a celý ekosystém je neuvěřitelně dobře navržený, pořád mě to nepřestává překvapovat, jak dobře to tenkrát udělali).
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 28. 01. 2017, 14:51:31
To zní dost dobře. Takže proč se nepoužívá víc? Znám třeba RabbitMQ, který je hodně populární. Ale třeba ActiveMQ umí cca to stejné a i stejně rychle. Takže v Erlangu by byl vývoj rychlejší? Je lépe udržovatelný? Nebo co je ta hlavní výhoda a zároveň proč se nepoužívá více?
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 15:19:49
To zní dost dobře. Takže proč se nepoužívá víc? Znám třeba RabbitMQ, který je hodně populární. Ale třeba ActiveMQ umí cca to stejné a i stejně rychle. Takže v Erlangu by byl vývoj rychlejší? Je lépe udržovatelný? Nebo co je ta hlavní výhoda a zároveň proč se nepoužívá více?
Pro nic z toho nemám žádná tvrdá data, takže těžko říct, můžu posloužit jenom mými subjektivními dojmy...

Subjektivně má Elixir trochu zvlněnou křivku učení - ty základy (syntaxe, moduly, funkce, protokoly) dá programátor v jiném jazyce tak za den, dva. Potom ale musí projít velkým mind-twistem, aby pochopil, jak se z nezávislých procesů, komunikujících jenom pomocí zpráv, stavějí větší systémy. U programátora bez zkušeností třeba s tím SmallTalkem nebo ObjC může tohle trvat docela dlouho. A pak nastává období, než ty patterny začne psát úplně automaticky. Teprve až projde tímhle, začíná být v Elixiru opravdu produktivní. Tohle by mohlo být spoustě lidem nepříjemný.

Druhá věc je, že se o Elixiru prostě neví (proto ho tady propaguju, protože podle mě stojí za pozornost pro každého programátora jako občerstvení a nakouknutí, jak se dají věci řešit i jinak...). O Erlangu se ví trochu víc, ale Erlang má dost nepříjemnou syntaxi, která asi hodně lidí odradí.

Třetí věc je, že co se týče hrubého výkonu, je Erlang (a tímpádem i Elixir) poměrně dost pomalý - v testech typu https://benchmarksgame.alioth.debian.org/ nemá šanci. To je tím, že byl původně navržený pro konkrétní problém (programování telefonních ústředen Ericsson) s návrhovými kritérii: 1. obrovský důraz na spolehlivost 2. masivní paralelizace 3. distribuovanost 4. možnost updatů za běhu (souvisí s 1). Rychlost byla požadovaná jenom na úrovni "soft-realtime". Hrubá rychlost number crunching nebyla cílem.

Čtvrtá věc je, že Erlang se nikdy nevezl na módní vlně, spíš přesně naopak - vznikal v době, kdy největší buzzword byl OOP a přitom šel do velké míry proti němu (v té jeho tehdejší módní podobě). Dneska už je to trochu jinak, do módy se dostává právě spíš FP a paralelismus, takže Elixir imho má celkem šanci, ale nějaký velký, masový úspěch bych mu nepredikoval, na to je málo easy, cool. Masový úspěch bych čekal spíš u Go.

Jinak, moje subjektivní zkušenost je taková, že jakmile jsem si na koncepty Elixiru zvykl, píše se mi v něm strašně příjemně, přirozeně - nemusím si strašlivě trápit hlavu a prostě si jenom tak hezky píšu a ono to funguje ;) Tím je to pro mě výrazně příjemnější než třeba to OOP, kde se pořád dokola řeší nějaké filosoficko-návrhové prkotiny typu co má být private, co dědit z čeho, co je "pravé" OOP, co je antipattern atd. atd. nebaví mě to, nechtěl bych se do tohodle světa vracet :)

Jinak objektivněji, Erlang má suprově navrženou knihovnu OTP, která umožňuje velice snadno dosáhnout věcí, které v jiných jazycích sice jdou třeba taky, ale je to hrozně náročný a spousta lidí si na tom vyláme zuby. Typicky ta distribuovanost a updaty za provozu. Proto si z OTP vzal příklad Akka framework a třeba takový Flink může díky němu poskytnout krásnou, jednoduchou a rock-solid distribuovanost hned ze startu - rozdíl např. oproti klasickým databázím, kde se podobné věci řeší desetiletí a pořád to tak nějak limitovaně funguje, ale sem tam jenom když je pátek odpoledne, bezvětří a nezapisuješ moc často ;)
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 15:35:48
Třetí věc je, že co se týče hrubého výkonu, je Erlang (a tímpádem i Elixir) poměrně dost pomalý - v testech typu https://benchmarksgame.alioth.debian.org/ nemá šanci.
Taky k tomu ještě doupřesnění, ať nevzniká mylnej dojem: z tohodle nijak neplyne nepoužitelnost pro praktické problémy nebo špatný výkon v reálných aplikacích. Zatímco třeba Python nebo Ruby jsou prostě pomalý a nemají to čím vyvážit, takže jediný způsob, jak s nima dělat něco použitelnýho, je začít využívat hrubé hacky jako nativní céčkové knihovny nebo kdovíjaké obcházení GILu, Erlang tu základní "hrubou" pomalost víc než vyvažuje právě tou parádní paralelizovatelností a ještě jinými drobnostmi, jako třeba elegantním garbage collectorem (díky nepřekročitelné immutabilitě), takže celkový výkon bývá velice příjemný.

Doporučuju třeba zkusit zagooglit "phoenix benchmark" - phoenix je Elixirovský webový framework s parádním výkonem.
Název: Re:Dědičnost dnes
Přispěvatel: gll 28. 01. 2017, 15:36:19
1. data jsou naprosto striktně immutable, nejde je měnit vůbec nijak (neexistuje ani žádný hack/pragma/meta/výjimka, která by to umožnila)

Data možná, ale hodnota proměnné lze změnit. Narozdíl od Erlangu.

Kód: [Vybrat]
iex(1)> fn -> a=1; a=2; a end.() 
2
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 15:41:09
Data možná, ale hodnota proměnné lze změnit. Narozdíl od Erlangu.

Kód: [Vybrat]
iex(1)> fn -> a=1; a=2; a end.() 
2
Opakuju: nemá  to vůbec žádné důsledky, je to jenom syntaktický cukr. Neplyne z toho, že by byl Elixir "míň striktní".

To elixirovské
Kód: [Vybrat]
a = 1
a = 2
f(a)
se prostě jakoby do Erlangu převede jako:
Kód: [Vybrat]
a1 = 1
a2 = 2
f(a2)
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 16:26:46
Tak jsem to pročetl... Je-li pan Armstrong spoluautorem Erlangu, je zarážející, že podstatu OOP naprosto, ale NAPROSTO nepochopil:
Ve tvrzeních o Armstrongovi bych byl opatrnější. Když člověk trochu zná výsledky jeho práce, vidí na vlastní oči, jak velice dobře různé problémy Erlangovský tým vyřešil. Člověk občas až žasne, jak u spousty problému zvolili řešení, které prozíravě předchází problémům, které se (ne)projeví až o několik tahů později. Působí to na mě jako přesný opak třeba javascriptového světa, kde každý krok typicky jeden problém vyřeší a deset nových způsobí :)

Objection 1: OOP oproti FP "data" a "funkce" spojuje z jednoduchého důvodu, a to, že data bez funkcí jsou k ničemu stejně tak jako funkce bez dat, přičemž funkce jsou vytvořeny pro daná data (to nevylučuje práci s obecnými daty jako v FP!). Myšlenka nutnosti nespojovat funkce a data jen z důvodu, že se jedná o jiné kategorie, je neopodstatněná (to ale neznamená, že to nejde).
Tam jde myslím spíš o to, že OOP svazuje konkrétní fce s konkrétními ("svými") daty a tím komplikuje (záměrně - a podle některých chybně) přístup k datům jinými fcemi.

Stupidní příklad: fce List.reverse(list) může fungovat nad listem čehokoli, protože o položkách nic nepředpokládá. Vesele teda jednou jedinou funkcí otáčím listy zákazníků, faktur i planet sluneční soustavy. Když chci totéž udělat u OOP, tak mi tenhle jeden problém exploduje do tisíce dalších: asi teda chci nějaké rozhraní IReversable, nebo chci nějak data zpřístupnit? Nebo pro každý objekt úplně nezávisle napíšu tutéž fci o.reverse()? Co je správně? Co je antipattern? Co porušuje zapouzdření? Neměl by objekt PlanetList dědit z List? No jo, ale já potřebuju, aby dědil z PlanetsOfSolarSystem. Co s tím? Vícenásobná dědičnost? Ale ne, to je fuj. atd.atd.atd. Armstrong tvrdí (nemusíš s ním souhlasit, ale myslím, že to nemůžeš jenom tak šmahem odbýt), že kdybys ty data nesvázal s konkrétními, předem danými funkcemi, měl bys míň problémů.

Objection 2: Různé třídy (typy; či prototypy) pro různé časové údaje se používají v implementacích OOP naprosto běžně - tento bod je nadbytečný.
Ten bod je spíš špatně vysvětlený. Nejde tam imho o to, že máš víc typů, ale že ty typy jsou "ubiquitous and data structures representing times can be manipulated by any function in the system" a že "There are no associated methods.". Čili to souvisí s předchozím a následujícím bodem. Např. na některé typy zachycující čas můžu v FP aplikovat List.reverse, když mi to bude dávat smysl. V OOP by nikdo nepředpokládal, že to budu chtít udělat, takže by neimplementoval IReversable, takže bych musel z Time dědit do svého MyReversableTime, který o IReversable rozšířím, jenže pak ho nemůžu serializovat stejně jako Time, protože na druhé straně MyReversableTime nemám a navíc ... (opět exploze pseudoproblémů)

Objection 3: Všudypřítomné "typy" se realizují třídami či prototypy. Poslední věta fabuluje cosi o nutnosti dědění.
Opět je tam klíčové to "ubiquitous". Prostě na jednom místě mám definováno, jakou strukturu mají data pojmenovaná "List" a používám to všude. Nepotřebuju řešit pseudoproblémy typu "Všechny objekty musí dědit z Object".

Objection 4: Objekty mají skryté stavy, ale nedávno mi tu pan Prýmek vysvětlil na Elixíru, že FP je má taky, akorát je jinak ukládá. Kde je potom rozdíl?
Říká tam, že stav nechceme, protože je s ním opruz, ale nějakým způsobem potřebujeme řešit, protože práce se stavem je cílem programování v reálném světě. Takže stav nějak ošetřit potřebujeme, máme na to několik možností. A Armstrong říká (opět s ním nemusíš souhlasit), že způsob práce se stavem, který zvolilo OOP, je nejhorší možný z dostupných.

---
Btw, velmi doporučuji se kouknout na video, kde Armstrong s Kayem diskutují. Neřekl bych, že by si nějak zvlášť vjížděli do vlasů. Spíš naopak - vypadá to, že oba dva se shodují na tom, že to, co se z OOP stalo, stojí za starou belu ;)

[EDIT: sorry, nějak jsem si spletl Kaye s Johnsonem ;) ]

https://www.infoq.com/interviews/johnson-armstrong-oop

Ještě je na YT jedno video s nima oběma, to jsem ale zatím neviděl.
Název: Re:Dědičnost dnes
Přispěvatel: gll 28. 01. 2017, 16:41:38
Data možná, ale hodnota proměnné lze změnit. Narozdíl od Erlangu.

Kód: [Vybrat]
iex(1)> fn -> a=1; a=2; a end.() 
2
Opakuju: nemá  to vůbec žádné důsledky, je to jenom syntaktický cukr. Neplyne z toho, že by byl Elixir "míň striktní".

To elixirovské
Kód: [Vybrat]
a = 1
a = 2
f(a)
se prostě jakoby do Erlangu převede jako:
Kód: [Vybrat]
a1 = 1
a2 = 2
f(a2)

Při zkoušení příkladů z tutoriálů (dál jsem se nedostal) je to užitečná vlastnost.

Jak funguje třeba funkce Map.put? Vytvoří kopii celé původní mapy nebo na ní odkáže?
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 16:44:39
Při zkoušení příkladů z tutoriálů (dál jsem se nedostal) je to užitečná vlastnost.
Ano, je to příjemná změna syntaxe.

Jak funguje třeba funkce Map.put? Vytvoří kopii celé původní mapy nebo na ní odkáže?
Já vlastně ani nevím a je mi to jedno ;) Dležitý je, že starou i novou mapu můžu pořád někam předávat  a nemusím se bát, že by mi je někdo změnil. Jestli to vnitřně nějaká data sdílí (předpokládám že jo), je mi jako programátorovi šuma fuk, mě zajímají ty vnější garance.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 28. 01. 2017, 17:29:54
Super, Mirku. Díky za info. Musím se tím probrat.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 28. 01. 2017, 17:47:56

Jinak, moje subjektivní zkušenost je taková, že jakmile jsem si na koncepty Elixiru zvykl, píše se mi v něm strašně příjemně, přirozeně - nemusím si strašlivě trápit hlavu a prostě si jenom tak hezky píšu a ono to funguje ;) Tím je to pro mě výrazně příjemnější než třeba to OOP, kde se pořád dokola řeší nějaké filosoficko-návrhové prkotiny typu co má být private, co dědit z čeho, co je "pravé" OOP, co je antipattern atd. atd. nebaví mě to, nechtěl bych se do tohodle světa vracet :)

S tím docela souhlasím. Hlavně to vidíš i tady. OOP Java podle některých není OOP. Dědičnost je podle některých super, podle jiných k ničemu. Pak v tom dělej :D
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 18:00:16
Super, Mirku. Díky za info. Musím se tím probrat.
Určitě se na Elixir koukni, fakt je to zajímavý i jenom na hraní, jako osvěžení. Kdyžtak klidně napiš třeba tady přes fórum, nebo si na mě vygoogli mail, rád s Elixirem pomůžu komukoli, je to pro dobro lidstva ;)
Název: Re:Dědičnost dnes
Přispěvatel: JS 28. 01. 2017, 18:51:38
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

Citace
To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.
Název: Re:Dědičnost dnes
Přispěvatel: gll 28. 01. 2017, 20:31:59
...

OOP v pythonu a podobných jazycích je jen syntaktický cukr, který usnadňuje psaní kódu pomocí autodoplňování. obj.metoda() je to stejné co Trida.metoda(obj). obj může být libovolného typu. Je možné sdílet metody Trida1.metoda = Trida2.metoda. V ničem to neomezuje. Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 28. 01. 2017, 20:57:53
Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.
Já myslím, že to kritici vidí trochu jinak: z OOP-jak-ho-dnes-každý-chápe je děláno zlaté tele, je přeceňován význam konkrétních konceptů, které zas tak zásadní nejsou (typicky ta dědičnost) na úkor jiných důležitých konceptů (třeba toho skládání nebo posílání zpráv), a takhle zmršené OOP se vydává za "to OOP" (čti zlaté tele).

Pokud by se místo C++ a Javy masově programovalo v ObjC, myslím, že by s tím nikdo neměl moc problém, protože problémy takového přístupu by byly srovnatelné s problémy jinde (there's no silver bullet). Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...
Název: Re:Dědičnost dnes
Přispěvatel: balki 28. 01. 2017, 22:25:27
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

Citace
To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

To su cisto filozoficke problemy.
1. ci nasobenie vektora a matice ma byt metoda vektora alebo matice, alebo brontosaura, o tom rozhoduje programator. Ak to dokaze logicky odovodnit, potom je to v poriadku.
2. kazdy oop (aj smalltalk) jazyk je  vskutocnosti multiparadigmovy, takze sa nikdy nevyhneme proceduralnym konstrukciam, pripadne funkcionalnym konstrukciam.
3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk. To, ze v niektorych modernejsich jazykoch su vzory nahraditelne idiomom znamena, ze uz vytvorili abstrakciu, ktora vzory zahrnuje, nie ze by ich spravili neuzitocnymi.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 29. 01. 2017, 11:14:36
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

Citace
To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

Jedna z možných implementací by byla např. takováto:

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.
Maticové násobení bude umět matice a realizováno bude pomocí skalárních součinů.
Čtvercová matice by byla potomkem obecné matice a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.
Název: Re:Dědičnost dnes
Přispěvatel: Ondra Satai Nekola 29. 01. 2017, 11:28:17
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Predne, abych se trochu opravil - jadro Armstrongova argumentu je ze skryvani dat uvnitr objektu vede k problemum.

Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?

(Jeste bych tady mohl vlozit otazku, jak implementovat ctvercovou matici, ale to uz se tady probiralo...)

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

Citace
To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

Jedna z možných implementací by byla např. takováto:

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.
Maticové násobení bude umět matice a realizováno bude pomocí skalárních součinů.
Čtvercová matice by byla potomkem obecné matice a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Permanent a determinant jsou dve ruzne (prestoze podobne) veci.
Název: Re:Dědičnost dnes
Přispěvatel: čumil 29. 01. 2017, 12:45:20
Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.
Já myslím, že to kritici vidí trochu jinak: z OOP-jak-ho-dnes-každý-chápe je děláno zlaté tele, je přeceňován význam konkrétních konceptů, které zas tak zásadní nejsou (typicky ta dědičnost) na úkor jiných důležitých konceptů (třeba toho skládání nebo posílání zpráv), a takhle zmršené OOP se vydává za "to OOP" (čti zlaté tele).

Pokud by se místo C++ a Javy masově programovalo v ObjC, myslím, že by s tím nikdo neměl moc problém, protože problémy takového přístupu by byly srovnatelné s problémy jinde (there's no silver bullet). Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...
Opravdu musím souhlasit, celí koncept dědičnosti je bullshit na osrani statického typování.
Název: Re:Dědičnost dnes
Přispěvatel: JS 29. 01. 2017, 14:19:58
To su cisto filozoficke problemy.

Nejsou, jak bys mohl nahlednout, kdyby sis zkusil je vyresit..

Citace
1. ci nasobenie vektora a matice ma byt metoda vektora alebo matice, alebo brontosaura, o tom rozhoduje programator. Ak to dokaze logicky odovodnit, potom je to v poriadku.

Ta hlavni otazka ovsem je, jak se z metody te jedne tridy dostanes k prvkum te druhe, kdyz aplikujes "data hiding". Ten priklad neni muj - pochazi z knizky C++ od Stroustrupa jako motivace pro spratelene tridy.

Ale mas castecne pravdu, je to jedna z veci, kterou OOP vytykam. Pokud totiz nebudes dusledny v data hiding, pak cela ta sarada s tridami nedava zadny smysl, a jsou to pseudoproblemy.

Citace
2. kazdy oop (aj smalltalk) jazyk je  vskutocnosti multiparadigmovy, takze sa nikdy nevyhneme proceduralnym konstrukciam, pripadne funkcionalnym konstrukciam.

Takze k cemu je podle tebe OOP dobre? Zase, tohle trochu napovida, ze to neni uplne promysleny koncept.

Citace
3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk.

Muj hlavni problem s navrhovymi vzory je v tom, ze jakmile budeme stejny koncept modelovat pomoci vic trid (treba v MVC - stejny widget ma casto svuj protejsek ve vsech trech pismenkach), a nikoli jako jen jednu tridu, pak cela myslenka OOP (a data hiding) se tak nejak stava zbytecnou. To uz muzeme rovnou delit svet na datove typy a funkce (coz jsou daleko jasneji definovane zalezitosti) a tridam se vyhnout uplne.
Název: Re:Dědičnost dnes
Přispěvatel: gll 29. 01. 2017, 14:55:01
3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk. To, ze v niektorych modernejsich jazykoch su vzory nahraditelne idiomom znamena, ze uz vytvorili abstrakciu, ktora vzory zahrnuje, nie ze by ich spravili neuzitocnymi.


to není pravda. V dynamických jazycích některé klasické návrhové vzory nedávají smysl.

http://mishadoff.com/blog/clojure-design-patterns/
Název: Re:Dědičnost dnes
Přispěvatel: JS 29. 01. 2017, 14:55:39
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.

Citace
Čtvercová matice by byla potomkem obecné matice

Asi jako ma byt ctverec potomkem obdelnika?

Citace
a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Mel to byt permanent, a z dobreho duvodu.  ;) U determinantu se da predpokladat, ze ho autor te tridy matice zahrnul jako metodu. Ale u permanentu.. uz to nebyva bezne. Ale co kdyz ja takovou metodu potrebuji?

Znovu opakuji fundamentalni otazku: Mam novy algoritmus a chci ho aplikovat na stavajici objekty (tridy). Jak to udelam, aniz bych porusil data hiding?

Ja jsem presvedceny o tom, ze data hiding je v podstate posetilost. Je to snaha vyhnout se slozite necemu, cemu se ve finale vyhnout neda.

Popisu strucne, jak by se takovy problem resil ve funkcionalnim programovani. Je to pomerne primocare. Kdo by psal ten algoritmus by ho parametrizoval nejakymi funkcemi (predanymi jako argument), ktere z obecnych objektu vyberou presne to, co ten algoritmus potrebuje znat, aby fungoval. V miste, kde se ten algoritmus vola, se pak takove funkce bud explicitne vytvori, nebo se pouziji uz existujici, a dodaji se spolu s temi konkretnimi objekty jako parametry toho algoritmu.

Takze napriklad, funkce pro vypocet permanentu potrebuje pristup k obecnemu prvku matice, takze bude parametrizovana funkci, ktera pro obecny typ (ktery bude predstavovat neco, co ma tu matici) a dany index vrati prislusny prvek. Autor algoritmu na vypocet permanentu tuto funkci nemusi znat.

Teprve v miste volani se zvoli tato funkce na zaklade struktury, s kterou chceme pracovat, a vlozi se jako parametr do toho algoritmu na vypocet permanentu. Ovsem k tomu, abychom tu funkci mohli zvolit, musime znat konretni vnitrni strukturu objektu, s kterym chceme pracovat, a tudiz musime porusit data hiding.

(Odbocka: Tohle reseni pak tak nejak prirozene vede k definici typovych trid - typova trida je vlastne soubor funkci, ktere muzeme volat nad ruznymi typy, neco jako interface, ale rozsiritelne.)

Chci zduraznit jednu vec - to funkcionalni reseni je v zasadni veci odlisne od pristupu, kdy treba ta trida matice poskytuje metodu, ktera vrati dany prvek. Kompilator totiz muze prislusnout funkci, ktera poskytuje prvky matice, zahrnout primo do prislusneho algoritmu a spolu s ni ho optimalizovat. Coz je v protikladu k data hiding, kde se ta metoda chape jako nejaka "poslana zprava". Ja nechci poslat zpravu, ja chci aby ten algoritmus mohl primo pracovat s prvky te matice. (Jinak vysvetleny ten rozdil jsem uz naznacil o x-prispevku driv - kdyz jsem psal o vyhodach FP vuci OOP - ze se jen predavaji stejna data je netrivialni poznat, ale ze se nekde vzdy aplikuje funkce identity pozna prekladac pomerne snadno.)
Název: Re:Dědičnost dnes
Přispěvatel: balki 29. 01. 2017, 15:38:09
To su cisto filozoficke problemy.

Nejsou, jak bys mohl nahlednout, kdyby sis zkusil je vyresit..

Citace
1. ci nasobenie vektora a matice ma byt metoda vektora alebo matice, alebo brontosaura, o tom rozhoduje programator. Ak to dokaze logicky odovodnit, potom je to v poriadku.

Ta hlavni otazka ovsem je, jak se z metody te jedne tridy dostanes k prvkum te druhe, kdyz aplikujes "data hiding". Ten priklad neni muj - pochazi z knizky C++ od Stroustrupa jako motivace pro spratelene tridy.

Ale mas castecne pravdu, je to jedna z veci, kterou OOP vytykam. Pokud totiz nebudes dusledny v data hiding, pak cela ta sarada s tridami nedava zadny smysl, a jsou to pseudoproblemy.

Citace
2. kazdy oop (aj smalltalk) jazyk je  vskutocnosti multiparadigmovy, takze sa nikdy nevyhneme proceduralnym konstrukciam, pripadne funkcionalnym konstrukciam.

Takze k cemu je podle tebe OOP dobre? Zase, tohle trochu napovida, ze to neni uplne promysleny koncept.

Citace
3. navrhove vzory boli vytvorene pre OOP jazyky vseobecne, neriesi sa nimi nedokonalost jazykov, ale su to vypozorovane vztahy objektov nezavisle na implementacii, ktore sa pouzivali v praxi. Vo fundamentalnej knihe od gang of four su priklady uvadzane v jazyku smalltalk.

Muj hlavni problem s navrhovymi vzory je v tom, ze jakmile budeme stejny koncept modelovat pomoci vic trid (treba v MVC - stejny widget ma casto svuj protejsek ve vsech trech pismenkach), a nikoli jako jen jednu tridu, pak cela myslenka OOP (a data hiding) se tak nejak stava zbytecnou. To uz muzeme rovnou delit svet na datove typy a funkce (coz jsou daleko jasneji definovane zalezitosti) a tridam se vyhnout uplne.

1.Dolezita je enkapsulacia, tj zviazanie objektu* s datami, to nemusi narusovat. Je mozne prvky matice, alebo vektoru spristupnit cez rozhranie. Ci to rozhranie poskytuje skutocnu maticu, dummy hodnoty, alebo vypocitane hodnoty, kopie hodnot je uz na samotnom objekte.  Data hiding je trosku o inom, to je o tom, aby nesiahal programator tam, kam nema. To je volitelne rozhodnutie programatora, ako napise svoje objekty, ci chce data schovavat (najcastejsie kvoli setreniu si vlastnych nervov), alebo poskytovat dalej.

2. OOP je dobre na to, ze umoznuje dalsiu uroven abstrakcie aplikacie.  Teda nie je nutne vediet nic o konkretnej vnutorenej reprezentacii, staci volat prislusne spravy. Ale to ze umoznuje, neznamena ze prikazuje. Ked si to biznis logika aplikacie vyzaduje, tak je mozne pouzit proceduralny pristup.

3. Model-view-controller je architektonicky vzor, nie navrhovy vzor. Sam je zlozeny z troch navrhovych vzorov. Observer, composite a strategy.  Navrhove vzory su iste overene opakujuce sa priklady z praxe riesenia urcitych problem (protichodnych sil) v urcitom kontexte. Je to dalsia uroven abstrakcie, ktora umoznuje opisy komplexnejsich foriem bez specifikovania detailov.

Pri architektonickom vzore mvc nejde o to, ze by jeden objekt existoval tri krat, ale ide o to, ze objekt z domenoveho sveta ma svoj obraz v objekte technologickeho sveta.  Nie je to problem objektoveho sveta ale je to problem pretinajucich zalezitosti (crosscuting concerns), ktore su v kazdej paradigme a bez nich by aplikacie neboli funkcne.


https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
https://en.wikipedia.org/wiki/Separation_of_concerns
http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html

*Schvalne pouzivam pojem objekty a nie triedy, kedze trieda-instancia je dualizmus vyjadrenia objektu a nie vzdy platny. Ale rozumiem, co je slovo trieda a co je instancia. A na objektoch netrvam.
Název: Re:Dědičnost dnes
Přispěvatel: gll 29. 01. 2017, 16:14:07
2. OOP je dobre na to, ze umoznuje dalsiu uroven abstrakcie aplikacie.

Přidávat úrovně abstrakce nemusí být vždy dobrý nápad.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 29. 01. 2017, 17:17:34
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.
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ě).

Citace
Čtvercová matice by byla potomkem obecné matice

Asi jako ma byt ctverec potomkem obdelnika?

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. Pokud jsem mezi ty operace zahrnul i možnost přidání/odebrání libovolného řádku/sloupce, tak, celkem logicky, předchozí věta neplatí. Zatímco u obdélníka mohu v určitých případech potřebovat změnit velikost stran, u matic to zrovna obvyklá věc není. Matice X má daný nějaký rozměr. Pokud ho změním, tak už to nebude matice X, ale přinejmenším X'. Kdybych to přesto potřeboval, pořád existují další možnosti, jako jsou sdružené třídy, skryté podtřídy, změna třídy, žádná podtřída...
(kdybych to potřeboval z toho důvodu, že dělám numerické operace s obrovskými maticemi, tak to budu dělat ve Fortranu a nebude mě to trápit vůbec)

Citace
a operace nad ní, jako třeba determinant (to měl být asi ten "permanent"?), by byly realizovány v jejím rámci.

Mel to byt permanent, a z dobreho duvodu.  ;) U determinantu se da predpokladat, ze ho autor te tridy matice zahrnul jako metodu. Ale u permanentu.. uz to nebyva bezne. Ale co kdyz ja takovou metodu potrebuji?

Tak ji přidám přímo do té třídy.
Název: Re:Dědičnost dnes
Přispěvatel: JS 29. 01. 2017, 19:23:53
1.Dolezita je enkapsulacia, tj zviazanie objektu* s datami, to nemusi narusovat. Je mozne prvky matice, alebo vektoru spristupnit cez rozhranie. Ci to rozhranie poskytuje skutocnu maticu, dummy hodnoty, alebo vypocitane hodnoty, kopie hodnot je uz na samotnom objekte.  Data hiding je trosku o inom, to je o tom, aby nesiahal programator tam, kam nema. To je volitelne rozhodnutie programatora, ako napise svoje objekty, ci chce data schovavat (najcastejsie kvoli setreniu si vlastnych nervov), alebo poskytovat dalej.

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).

Rozumim tomu, proc je enkapsulace oblibena v jazycich, ktere pochazeji (rekneme) z C, kde prirazeni a volani funkce jsou dve ruzne veci. Tam ma smysl abstrahovat prirazeni jako funkci. Ale ve funkcionalnich jazycich to tak uz je (protoze tam prirazeni neni), a pokud tedy nebudes delat ten "data hiding", tak to ani nepotrebujes delat.

Kdyz ve funkcionalnim programu definuji nejaky datovy typ, a pak definuji funkci, ktera ten datovy typ bere jako argument, svazal jsem funkce a data. Nemusim deklarovat zadny objekt, k cemu? Je to uz enkapsulovane.

Takze, pointa je, ze z pohledu FP je enkapsulace (bez skryvani dat) prazdny koncept. Takze se muzeme podivat dal a vidime, ze skryvani dat pak prinasi jen nevyhody, a tedy to odmitnout jako nesmysl.

Citace
2. OOP je dobre na to, ze umoznuje dalsiu uroven abstrakcie aplikacie.  Teda nie je nutne vediet nic o konkretnej vnutorenej reprezentacii, staci volat prislusne spravy. Ale to ze umoznuje, neznamena ze prikazuje. Ked si to biznis logika aplikacie vyzaduje, tak je mozne pouzit proceduralny pristup.

Moje otazka je, co ti tato abstrakce prinasi navic oproti funkcni abstrakci (funkcim). Podle me nic, coz je videt z toho, ze objekty muzeme simulovat pomoci funkci (pres uzavery). K cemu tedy mit v jazyce tento koncept navic.

Citace
Navrhove vzory su iste overene opakujuce sa priklady z praxe riesenia urcitych problem (protichodnych sil) v urcitom kontexte. Je to dalsia uroven abstrakcie, ktora umoznuje opisy komplexnejsich foriem bez specifikovania detailov.

Stejna namitka jako predtim. Proc ti nestaci funkcni abstrakce? Ve skutecnosti bylo ukazano, ze spousta navrhovych vzoru (pokud ne vsechny) lze modelovat pomoci funkci. Matematikum staci funkce.. Je to jenom zavadeni zbytecnych pojmu (ktere navic nejsou az tak zazracne vystizne, jelikoz nejsou uplne presne formalne definovane).

Ono by to bylo na delsi debatu... Ale v zasade jde o to, ze pokud se pokusime vetsinu tech vzoru nejak konkretneji uchopit, hodne rychle se to rozpadne na neco velmi trivialniho, co si vlastne ani jmeno moc nezaslouzi, protoze vysvetleni, jak to aplikovat, je delsi, nez popis pomoci treba funkci.

V podstate je mi tech GoF autoru (a podobnych vynalezcu) lito, protoze se heroicky snazi vyrobit neco nad OOP, co uz matematici udelali v FP a nekolikrat lepe (predevsim formalne presneji).

Citace
Pri architektonickom vzore mvc nejde o to, ze by jeden objekt existoval tri krat, ale ide o to, ze objekt z domenoveho sveta ma svoj obraz v objekte technologickeho sveta.

Ja si myslim, ze pokud bys OOP aplikoval dusledne, bude to zridkakdy pravda - na jeden objekt z domenoveho sveta budes potrebovat vicero objektu v programovacim jazyce. Coz naznacuje, ze to neni uplne dobry popis.
Název: Re:Dědičnost dnes
Přispěvatel: JS 29. 01. 2017, 19:40:05
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.

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.

Citace
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.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 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.
Název: Re:Dědičnost dnes
Přispěvatel: v 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
Název: Re:Dědičnost dnes
Přispěvatel: balki 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.

Potom budem schopny polemizovat, lebo zatial nechapem suvislosti.

Dakujem :)
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 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á ;)
Název: Re:Dědičnost dnes
Přispěvatel: gll 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.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 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.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 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í.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 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 :)
Název: Re:Dědičnost dnes
Přispěvatel: SB 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.
Název: Re:Dědičnost dnes
Přispěvatel: SB 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.
Název: Re:Dědičnost dnes
Přispěvatel: v 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 :)
Název: Re:Dědičnost dnes
Přispěvatel: SB 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.
Název: Re:Dědičnost dnes
Přispěvatel: SB 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í.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 08:47:17
V JavaScriptu vse objekt neni, ma primitivni (https://developer.mozilla.org/en-US/docs/Glossary/Primitive) 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.
Název: Re:Dědičnost dnes
Přispěvatel: SB 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.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 09:11:15
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.

Nuda, operujete tu s terminom "ciste oop", ani poriadne neviete podlozit, co to je. Termin dynamicky typovany je oproti roznym "pozdnim vazbam" a podobnym laxne definovanym frikulinstinam bezne zauzivana terminologia.  Tu je clanok z root https://www.root.cz/clanky/staticka-dynamicka-typova-kontrola/.  Tu je wikipedia  https://en.wikipedia.org/wiki/Type_system. Literaturu smalltalkarov som cital v ramci studia, ale iba seriozne publikacie.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 09:23:05
Jak vis, ze nerozumi OOP? Zato vime, ze ty neznas FP.. Me prijde, ze tak trochu popiras, ze by sly veci delat lepe.
...
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Ono ostatne i existence mnoha "design patterns" naznacuje, ze takova ta originalni predstava OOP, ze lze pomoci trid modelovat domenove objekty, tak docela nevysla.

Jeho odpovědi nedávají smysl, se slávou to nemá co dělat. Koncept rozdělení dat a funkcí jsem pochopil, neměnitelné stavy dosud neviděl. To tvrdíte vy.
Matici a vektor rozepište.
Možná by bylo vhodné připomenout nevýhody rozdělení ve FP.
V čem spočívá ta chyba tříd?
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 09:48:03
Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable.
Tady nebezpečně motáš pojmy. Mutabilita se týká dat. Co je "mutabilita modulu", to bysme si museli nějak zadefinovat, jinak to bude plácání o koze a o voze :)

Tohle by bylo třeba dořešit, protože tu vznikl dojem, že FP je tak nějak celé immutable, což mi bylo hned od začátku jasné, že je to hovadina. Proto jsem se ptal, jak přechází systém (jako celek) mezi stavy.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 30. 01. 2017, 09:50:55
Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable.
Tady nebezpečně motáš pojmy. Mutabilita se týká dat. Co je "mutabilita modulu", to bysme si museli nějak zadefinovat, jinak to bude plácání o koze a o voze :)

Tohle by bylo třeba dořešit, protože tu vznikl dojem, že FP je tak nějak celé immutable, což mi bylo hned od začátku jasné, že je to hovadina. Proto jsem se ptal, jak přechází systém (jako celek) mezi stavy.
Čisté FP je immutable.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 09:51:52
Jde, ale je to míň praktické - musím pro každé volání rezervovat thread/process. Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.

To samé mě napadlo - jestliže mám asynchronně bezpečný model, můžu pro spouštění zpracování fronty (bez ohledu na její implementaci) jednotlivých objektů/aktorů používal libovolný počet (1-n) vláken přepínáním kontextu.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 30. 01. 2017, 09:52:23
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ší...

Když to celé někdo (autoři C++, autoři Javy) nesprávně pochopili a nesprávně implementovali, tak je taková úvaha správná. Jenže to se pak nebavíme o objektovém, ale o jakémsi podtřídně-typovém programová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

Možná jo, i když za těch 30 let, co se motám kolem počítačů, už na žádné zázračné stříbrné kulky, co dokážou skolit každý problém jedinou ranou, fakt věřit nezačnu. Jednu nesnáz vyřeší, další dvě způsobí. Ale když už porovnávat a vylepšovat, tak pro boha ne s javským (nebo nedej bože dokonce C++kovým), ale se smalltalkovským pojetí OOP. Pak totiž třeba přijdeš na to, že všechny ty pseudoproblémy OOP jsou ve skutečnosti problémy Javy nebo C++ a jejich podtřídně-typového programování, ale ne samotného objektového programování, s nímž mají společnou vážně jen možnost odvozovat podtřídy.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 30. 01. 2017, 10:22:33
Tohle by bylo třeba dořešit, protože tu vznikl dojem, že FP je tak nějak celé immutable, což mi bylo hned od začátku jasné, že je to hovadina. Proto jsem se ptal, jak přechází systém (jako celek) mezi stavy.
"Tak nějak celé immutable" nevím, co znamená. V čistém FP jsou data immutable a ohledně fcí platí referenční transparentnost. Tyhle dvě věci asi celkem stačí na popis toho, o co jde, víc není potřeba říkat.

Jak (čistě funkcionální) celej přechází mezi stavy už tady bylo řečeno víckrát: "uvnitř jazyka" nic nikam nepřechází, protože celý systém je de facto čistě statický. To, co nějak mění stav, je runtime (na základě těch statických instrukcí).
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 30. 01. 2017, 10:23:28
Možná jo, i když za těch 30 let, co se motám kolem počítačů, už na žádné zázračné stříbrné kulky, co dokážou skolit každý problém jedinou ranou, fakt věřit nezačnu. Jednu nesnáz vyřeší, další dvě způsobí. Ale když už porovnávat a vylepšovat, tak pro boha ne s javským (nebo nedej bože dokonce C++kovým), ale se smalltalkovským pojetí OOP. Pak totiž třeba přijdeš na to, že všechny ty pseudoproblémy OOP jsou ve skutečnosti problémy Javy nebo C++ a jejich podtřídně-typového programování, ale ne samotného objektového programování, s nímž mají společnou vážně jen možnost odvozovat podtřídy.
Naprostý souhlas, v tomhle nejsme v žádném sporu.
Název: Re:Dědičnost dnes
Přispěvatel: ava 30. 01. 2017, 10:24:06
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 :)

Ahoj,
mrkni na přednášku https://www.youtube.com/watch?v=Rmer37g9AZM , mohlo by to být pro tebe zajímavé.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 10:56:12

Objection 1: OOP oproti FP "data" a "funkce" spojuje z jednoduchého důvodu, a to, že data bez funkcí jsou k ničemu stejně tak jako funkce bez dat, přičemž funkce jsou vytvořeny pro daná data (to nevylučuje práci s obecnými daty jako v FP!). Myšlenka nutnosti nespojovat funkce a data jen z důvodu, že se jedná o jiné kategorie, je neopodstatněná (to ale neznamená, že to nejde).
Tam jde myslím spíš o to, že OOP svazuje konkrétní fce s konkrétními ("svými") daty a tím komplikuje (záměrně - a podle některých chybně) přístup k datům jinými fcemi.

Stupidní příklad: fce List.reverse(list) může fungovat nad listem čehokoli, protože o položkách nic nepředpokládá. Vesele teda jednou jedinou funkcí otáčím listy zákazníků, faktur i planet sluneční soustavy. Když chci totéž udělat u OOP, tak mi tenhle jeden problém exploduje do tisíce dalších: asi teda chci nějaké rozhraní IReversable, nebo chci nějak data zpřístupnit? Nebo pro každý objekt úplně nezávisle napíšu tutéž fci o.reverse()? Co je správně? Co je antipattern? Co porušuje zapouzdření? Neměl by objekt PlanetList dědit z List? No jo, ale já potřebuju, aby dědil z PlanetsOfSolarSystem. Co s tím? Vícenásobná dědičnost? Ale ne, to je fuj. atd.atd.atd. Armstrong tvrdí (nemusíš s ním souhlasit, ale myslím, že to nemůžeš jenom tak šmahem odbýt), že kdybys ty data nesvázal s konkrétními, předem danými funkcemi, měl bys míň problémů.

...


Myslím, že jste si na ony připomínky odpověděl sám - všechna použití, co jste uvedl, jsou použití seznamu (List), a proto budou mít též jeho vlastnosti - je-li něčeho řada a je třeba jí otočit pořadí, téměř jistě se bavíme o seznamu, který toto již dávno umí. Je-li třeba použít jiný než obecný seznam (a to je otázka!), vždy jej lze specializovat, případně (u vaší obavy) při různých speciálních vlastnostech složit a zvláštnosti doplnit. Ani trait na to není třeba (osobně bych to ani nedělal). List JE ubiquitous a obecný, není třeba jej implementovat opakovaně na mnoha místech pomocí sady funkcí, pod kterou stejně bude ležet nějaká datová struktura seznamu.
Možná jste zvolil nevhodný příklad, nebo vyrábíte problém, kde není. To je můj názor, neberte to jako boj. ;)
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 30. 01. 2017, 10:58:56
Myslím, že jste si na ony připomínky odpověděl sám - všechna použití, co jste uvedl, jsou použití seznamu (List), a proto budou mít též jeho vlastnosti - je-li něčeho řada a je třeba jí otočit pořadí, téměř jistě se bavíme o seznamu, který toto již dávno umí. Je-li třeba použít jiný než obecný seznam (a to je otázka!), vždy jej lze specializovat, případně (u vaší obavy) při různých speciálních vlastnostech složit a zvláštnosti doplnit. Ani trait na to není třeba (osobně bych to ani nedělal). List JE ubiquitous a obecný, není třeba jej implementovat opakovaně na mnoha místech pomocí sady funkcí, pod kterou stejně bude ležet nějaká datová struktura seznamu.
Možná jste zvolil nevhodný příklad, nebo vyrábíte problém, kde není. To je můj názor, neberte to jako boj. ;)
Podstata je v tom, že když se programátor v záchvatu oop-vitosti rozhodne ten list uvnitř objektu skrýt, tak na něm ten reverse neudělám.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 11:49:11
Jak funguje třeba funkce Map.put? Vytvoří kopii celé původní mapy nebo na ní odkáže?
Já vlastně ani nevím a je mi to jedno ;) Dležitý je, že starou i novou mapu můžu pořád někam předávat  a nemusím se bát, že by mi je někdo změnil. Jestli to vnitřně nějaká data sdílí (předpokládám že jo), je mi jako programátorovi šuma fuk, mě zajímají ty vnější garance.

Zde pořád nějak nevidím tu výhodu FP od OOP (teď nemám na mysli optimalizaci a paralelizaci, ale model) - když potřebuju objekt immutable, udělám si ho, když ne, nic mě nenutí. Rozhoduju se dle použití.
Název: Re:Dědičnost dnes
Přispěvatel: Mirek Prýmek 30. 01. 2017, 11:56:09
Zde pořád nějak nevidím tu výhodu FP od OOP (teď nemám na mysli optimalizaci a paralelizaci, ale model) - když potřebuju objekt immutable, udělám si ho, když ne, nic mě nenutí. Rozhoduju se dle použití.
Jedna z výhod je nabíledni: pokud si můžu vybrat, potom o výsledku neexistuje žádná garance.

Pokud jsou data zaručeně imutabilní => mám garanci, že obsahují jenom backward reference (nemůžou tam z principu být cykly) => můžu mít např. výrazně efektivnější GC.

Můžu si vybrat => garance není => musím počítat s nejhorší variantou => v nejhorším případě jsem si vybral imutabilitu a přesto z ní nemůžu těžit.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 12:16:33
Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?
...
Mame operaci nasobeni matice a vektoru - patri do tridy matice, nebo do tridy vektor? A pokud si jednu vybereme, jak se dostaneme k prvkum te druhe? (Samozrejme, muzeme modelovat oboji jako matici, ale pak jsme se ponekud vyhnuli tomu skryvani.)

Jiny priklad. Mame tridu matice, a ta ma nejake metody. Potrebuji spocitat permanent, ale na to tam metoda neni. Jak to implementovat, aniz bych nemel pristup k vnitrnostem te tridy matice?
...

Nebo obecne, vezmi si jakykoli algoritmus. Je existence toho algoritmu vlastnosti objektu, s kterymi pracuje? Je treba moznost vypoctu maximalniho toku vlastnosti elektricke site? Zda se mi, ze ne. Jenze ten algoritmus typicky o tech objektech neco predpoklada a potrebuje k nim pristupovat. Takze pro implementaci toho algoritmu neni lhostejne, jaka je vnitrni struktura tech objektu.

Jsou situace, kde OOP funguje pomerne dobre - treba GUI. Protoze na to v naivni implementaci zadny algoritmus nepotrebujes. Tam pokud spolu veci nejak musi interagovat, tak maji spolecneho predka (treba Widget). OOP je proste postavene na nejake analogii s realnym svetem, ktery tak nejak prirozene delime do objektu, a prisuzujeme jim duvod, proc neco delaji. Ale to je do jiste miry dost nepresny popis reality a na mnoho problemu selhava.

Citace
To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Ano, zajima me to v Jave, to je kanonicky pripad jazyka, co pouzivaji zastanci OOP. Ale klidne muzes naznacit, jak bys to resil ve Smalltalku; pochybuji, ze pujde o skutecne skryvani dat.

Ufff, to je hukot...

Matici je možno modelovat vektory, pak půjde o skládání!!! Dědičnost tu nemá co pohledávat! Nebo je možno matici modelovat bez vektorů, aniž by to mělo vliv na funkcionalitu. Provedení je ponecháno na soudruhovi.
K čemu je mi matice či vektor, do kterého nevidím?!!! Neboli asi budou immutable, ale není důvod, aby jejich hodnoty nebyly viditelné!

Chybí metoda? Je několik možností:
1. Specializace: vytvořit podtřídu - její zvláštností je, že umí něco navíc. V pořádku.
2. Extended method (u některých jazyků).
3. V Smalltalku: třídy (i z jiných balíčků) je možno běžně rozšiřovat o vlastní metody (ve svých balíčcích), takže stačí doplnit.
4. Skládání: Vyrobím objekt, který bude obsahovat původní matici (její vytvoření ap.), a doplním jej o požadovanou metodu. V jazyku s pozdní vazbou (Smalltalk, ...) to mám o to jednodušší, že na předelegování metod seru a vyřeším je jedním vrzem přeposláním zprávy z doesNotUnderstand (to kdyby někdo potřeboval vědět, na co že ta hovadina je).
5. Vždy (jako všude jinde) můžu třídu vyrobit znovu, nechci-li použít něco existujícího.

Opět snadná uchopitelnost OOP v GUI, protože to jde vidět?

Takže opět a pořád dokola: Chyba není v OOP, ale v znalosti jeho použití.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 12:21:55
...Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...

Jinak řečeno se jedná o únos termínu OOP.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 12:37:04
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ší...

Když to celé někdo (autoři C++, autoři Javy) nesprávně pochopili a nesprávně implementovali, tak je taková úvaha správná. Jenže to se pak nebavíme o objektovém, ale o jakémsi podtřídně-typovém programová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

Možná jo, i když za těch 30 let, co se motám kolem počítačů, už na žádné zázračné stříbrné kulky, co dokážou skolit každý problém jedinou ranou, fakt věřit nezačnu. Jednu nesnáz vyřeší, další dvě způsobí. Ale když už porovnávat a vylepšovat, tak pro boha ne s javským (nebo nedej bože dokonce C++kovým), ale se smalltalkovským pojetí OOP. Pak totiž třeba přijdeš na to, že všechny ty pseudoproblémy OOP jsou ve skutečnosti problémy Javy nebo C++ a jejich podtřídně-typového programování, ale ne samotného objektového programování, s nímž mají společnou vážně jen možnost odvozovat podtřídy.

Spíše jestli to nechápeš špatně ty. Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali. Neříkám, že musejí být lepší než ty, ale podle těch tvých hlášek tady pochybuju, že bys uměl programovat. Pokud máš problém jen s tím, že Java je OOP, tak je na čase si to tu pro tu debatu trochu změnit.

Takže ještě jednou, proč se používá skoro na všechno Java, když je tak špatná? Dyť by ti podnikatelé raději mohli ušetřit a prodávat luxusní věci, ne? Neříkám, že je úžasná na všechno, ale ty máš určitě hromadu lepších přístupů, které plno problémů odstraní. A nebo jsi jen nic pořádného nedělal, nevím.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 12:38:08
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 :)

Ahoj,
mrkni na přednášku https://www.youtube.com/watch?v=Rmer37g9AZM , mohlo by to být pro tebe zajímavé.

Dik pozrem, aj ked to vyzera ako convention a nie seriozna konferencia. Mozno bude mat nejaky point.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 12:40:02
...Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...

Jinak řečeno se jedná o únos termínu OOP.

Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 12:52:26
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...
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á ;)

Kiwi to napsal dobře.
Problém je hlavně v tom, že když se něco "zdá", tak to ještě nemusí znamenat "je". To je příčina, na kterou obvykle dojedou začátečníci.
Nikdo přece nevyžaduje, aby všechny třídy byly v jednom stromu.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 12:54:53
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 :)

Ahoj,
mrkni na přednášku https://www.youtube.com/watch?v=Rmer37g9AZM , mohlo by to být pro tebe zajímavé.

Dik pozrem, aj ked to vyzera ako convention a nie seriozna konferencia. Mozno bude mat nejaky point.

Jedine co robil bolo, ze vyberal spravanie s objektov. Nic zaujimave. Ziadna analyzu ci spravil identicku vec nebola. Len to skonstatoval.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 12:57:15
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 :)

Tak pro někoho každopádně.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 12:57:47

Jedine co robil bolo, ze vyberal spravanie s objektov. Nic zaujimave. Ziadna analyzu ci spravil identicku vec nebola. Len to skonstatoval.

Taky ti trochu uniká, co se tu vlastně řeší? Když tu někdo ukáže "lepší" přístup, tak má zase hromady jiných problémů. A zároveň dnešní OOP se ukazuje jako velmi dobré i na obrovské věci.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 12:59:19
Nuda, operujete tu s terminom "ciste oop", ani poriadne neviete podlozit, co to je. Termin dynamicky typovany je oproti roznym "pozdnim vazbam" a podobnym laxne definovanym frikulinstinam bezne zauzivana terminologia.  Tu je clanok z root https://www.root.cz/clanky/staticka-dynamicka-typova-kontrola/.  Tu je wikipedia  https://en.wikipedia.org/wiki/Type_system. Literaturu smalltalkarov som cital v ramci studia, ale iba seriozne publikacie.

Na tohle fakt nemám.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 13:03:36
"Tak nějak celé immutable" nevím, co znamená. V čistém FP jsou data immutable a ohledně fcí platí referenční transparentnost. Tyhle dvě věci asi celkem stačí na popis toho, o co jde, víc není potřeba říkat.

Jak (čistě funkcionální) celej přechází mezi stavy už tady bylo řečeno víckrát: "uvnitř jazyka" nic nikam nepřechází, protože celý systém je de facto čistě statický. To, co nějak mění stav, je runtime (na základě těch statických instrukcí).

Supr, tak se k tomu začínáme posunovat: V runtime se nějakým způsobem udržují stavy. Od tohoto se můžeme odpíchnout.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 13:14:07

Jedine co robil bolo, ze vyberal spravanie s objektov. Nic zaujimave. Ziadna analyzu ci spravil identicku vec nebola. Len to skonstatoval.

Taky ti trochu uniká, co se tu vlastně řeší? Když tu někdo ukáže "lepší" přístup, tak má zase hromady jiných problémů. A zároveň dnešní OOP se ukazuje jako velmi dobré i na obrovské věci.

Hlavne ten pan vyberal von z objektu spravanie. Kontext aplikacie musel mat naviac vedomost spravania. Cize v konecnom dosledku zhorsil znovupouzitelnost. Kebyze toto skusi na OOPSLA, alebo na ECOOP, tak by to nepreslo ani peer review. Niekedy ale aj na dev convetions zvyknu mat dobre myslienky no, tento vylial dieta aj s vanickou a ani si nedal pracu vysvetlit ze preco, len konstatoval.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 13:30:17
Podstata je v tom, že když se programátor v záchvatu oop-vitosti rozhodne ten list uvnitř objektu skrýt, tak na něm ten reverse neudělám.

Tak buďto to má nějaký důvod, nebo je debil. Ale opět: S OOP to nemá co dělat, neschopnost vývojáře nebudu řešit tím, že rezignuju na zapouzdření. (https://en.wikipedia.org/wiki/Anemic_domain_model (https://en.wikipedia.org/wiki/Anemic_domain_model), https://en.wikipedia.org/wiki/Object_orgy (https://en.wikipedia.org/wiki/Object_orgy))
Název: Re:Dědičnost dnes
Přispěvatel: zboj 30. 01. 2017, 13:34:16
Matici je možno modelovat vektory, pak půjde o skládání!!!
V žádné rozumné implementaci nebude matice implementovaná jako kompozice vektorů, tím by byl přístup jen k řádkům nebo sloupcům. Nejflexibilnější řešení je mít obecnou kolekci pro vícerozměrné pole (pro modelování tenzorů) s metodami charakteristickými pro matice a vektory. Pro různé pohledy na příslušná data se použijí views nebo slices, tedy "něco jako" rozhraní. Nejen že to je takto nejefektivnější, ale zároveň se dodrží myšlenka "čistého" OOP (chceme-li na ní trvat). Praktický problém s takovouto implementací je jen jeden: ve většině jazyků to takto nepůjde (mně známými výjimkami jsou Smalltalk, ObjC a možná Swift).
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 13:37:54
Zde pořád nějak nevidím tu výhodu FP od OOP (teď nemám na mysli optimalizaci a paralelizaci, ale model) - když potřebuju objekt immutable, udělám si ho, když ne, nic mě nenutí. Rozhoduju se dle použití.
Jedna z výhod je nabíledni: pokud si můžu vybrat, potom o výsledku neexistuje žádná garance.

Pokud jsou data zaručeně imutabilní => mám garanci, že obsahují jenom backward reference (nemůžou tam z principu být cykly) => můžu mít např. výrazně efektivnější GC.

Můžu si vybrat => garance není => musím počítat s nejhorší variantou => v nejhorším případě jsem si vybral imutabilitu a přesto z ní nemůžu těžit.

Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 13:47:31
Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D

Budeme radši říkat netypované (protože u zasílání zpráv se nic netypuje/netříduje, alespoň ne na straně odesílatele). Ano, to je původní koncept (důsledky a použití zde byly uvedeny).
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 13:50:36
Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D

Budeme radši říkat netypované (protože u zasílání zpráv se nic netypuje/netříduje, alespoň ne na straně odesílatele). Ano, to je původní koncept (důsledky a použití zde byly uvedeny).

Super, díky. Tak to trochu promyslím, jestli z toho lze získat nějaké výhody. Protože pokud je třeba Smalltalk fakt lepší než Java, tak je zbytečné ji používat a čím dřív začnu, tím lépe.
Název: Re:Dědičnost dnes
Přispěvatel: noef 30. 01. 2017, 13:51:16
...
Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.

Rekl bych, ze uplne stejne jako v relacni DB - tj. idcka (ale nejsem zadny guru ;D, tak treba to jde i jinak).
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 13:55:05
V žádné rozumné implementaci nebude matice implementovaná jako kompozice vektorů, tím by byl přístup jen k řádkům nebo sloupcům. Nejflexibilnější řešení je mít obecnou kolekci pro vícerozměrné pole (pro modelování tenzorů) s metodami charakteristickými pro matice a vektory...

Klidně tenzory nebo fázory, o to tu nejde, podstatou bylo odpálkovat jakékoliv pokusy o hledání specializace/generalizace mezi maticí a vektorem.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 30. 01. 2017, 13:55:24
...
Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.

Rekl bych, ze uplne stejne jako v relacni DB - tj. idcka (ale nejsem zadny guru ;D, tak treba to jde i jinak).
Je to podobné jako problém autoreference v logice, prostě se vytvoří další metaúroveň (akorát se jí tak neříká).
Název: Re:Dědičnost dnes
Přispěvatel: zboj 30. 01. 2017, 13:57:52
V žádné rozumné implementaci nebude matice implementovaná jako kompozice vektorů, tím by byl přístup jen k řádkům nebo sloupcům. Nejflexibilnější řešení je mít obecnou kolekci pro vícerozměrné pole (pro modelování tenzorů) s metodami charakteristickými pro matice a vektory...

Klidně tenzory nebo fázory, o to tu nejde, podstatou bylo odpálkovat jakékoliv pokusy o hledání specializace/generalizace mezi maticí a vektorem.
Fázory asi těžko. Jinak ta specializace tam samozřejmě je (velice zřetelná), jen u dimenzí v řádech tisíců a více vůbec nic nepřináší.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 30. 01. 2017, 13:58:23
Spíše jestli to nechápeš špatně ty. Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali. Neříkám, že musejí být lepší než ty, ale podle těch tvých hlášek tady pochybuju, že bys uměl programovat. Pokud máš problém jen s tím, že Java je OOP, tak je na čase si to tu pro tu debatu trochu změnit.

Takže ještě jednou, proč se používá skoro na všechno Java, když je tak špatná? Dyť by ti podnikatelé raději mohli ušetřit a prodávat luxusní věci, ne? Neříkám, že je úžasná na všechno, ale ty máš určitě hromadu lepších přístupů, které plno problémů odstraní. A nebo jsi jen nic pořádného nedělal, nevím.

Tak jinak. "OOP" tak, jak ho nabízí C++ či Java, je jenom určitý odvar z OOP. To není jen má původní myšlenka, to v mnoha rozhovorech říkají i otcové-zakladatelé OOP. Jistě autory těch dvou výše zmiňovaných jazyků vedly určité záměry, proč zvolili zrovna tuto podmnožinu. Osobně si myslím, že to bylo z toho důvodu, že na určitý okruh problémů to stačí - typicky GUI a určitý druh aplikačního software. Např. jinak neobjektový Oberon má oproti Pascalu možnost definovat záznam přidáním dalších položek analogickou cestou, jakou se odvozuje podtřída. To je vše a stačí mu to. Další důvod je asi ten, že to původní, plně dynamické pojetí, je výpočetně náročnější. Smalltalk byl navržen pro počítač, který byl oproti v té době běžným asi tak o dvě generace napřed.
No a u Javy speciálně podle mne sehrálo největší roli to, že za ní stála silná korporace.
Pokud jde o to původní OOP, tak z prakticky používaných a oblíbených jazyků se mu nejvíc blíží Objective C (podle githubu a počtu debat na stackoverflow je v první desítce jazyků) nebo Ruby (také v první desítce, takže bych netvrdil, že to nikdo nepoužívá, i když podobné statistiky je vždycky dobré brát s určitou rezervou).

Ovšem nic z výše uvedeného nemění nic na faktu, že objektově orientované programování je trošku něco jiného než Java. A že problémy, které jsou představovány jako problémy OOP, jsou ve skutečnosti problémy Javy. Jinou otázkou je, jak moc jsou ty problémy v praxi palčivé a nakolik jsou spíš akademické. Dalším nemilosrdným faktem je taky skutečnost, že průměrný program v Javě je stále mnohonásobně rychlejší a méně náročnější na paměť než program ve Smalltalku, ale i Objective C.

Možná tu budím dojem nějakého advokáta smalltalkovského OOP. Ve skutečnosti se jen pokouším vyvrátit určité předsudky a omyly ohledně OOP. Sám jsem se s "OOP" poprvé setkal u Turbo Pascalu a u Borland C++ na začátku 90. let, spolu se jejich slavným Turbo Vision, a celý ten koncept mi připadal takový nějaký zbytečný, obzvláště když člověk zná Xaw nebo GTK. Teprve na Smalltalku mi docvaklo, co se tím ve skutečnosti myslí a jaká "kouzla" se s tím dají dělat. Ale ne v C++ ani v Javě. Sám jsem moc příležitostí profesionálně se tím zabývat neměl, vlastně jen asi půl roku jsem měl co do činění s Objective C a s Cocoa, ovšem musím říci, že to byla celkem příjemná zkušenost. Jinak mě živí C++ a dříve sem tam i ta Java. Ale jako embeďák je to především to C++. A bohužel musím konstatovat, že ve většině případů, s nimiž se setkávám, bylo upřednostnění C++ před C nešťastným krokem, protože to žádný benefit nepřineslo. Jen samá negativa.
Název: Re:Dědičnost dnes
Přispěvatel: SB 30. 01. 2017, 13:58:53
Je to podobné jako problém autoreference v logice, prostě se vytvoří další metaúroveň (akorát se jí tak neříká).

Tak zde musím přiznat, že jsem mimo, nic mi to nepřipomíná.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 14:00:51
Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D

Budeme radši říkat netypované (protože u zasílání zpráv se nic netypuje/netříduje, alespoň ne na straně odesílatele). Ano, to je původní koncept (důsledky a použití zde byly uvedeny).

Ako sa to vezme, objekt vzdy smalltalku nesie o sebe vedomost, akeho je typu/triedy. Je na programatorovi, ci sa na ten typ spyta (Ci ocakava nejake rozhranie, alebo nejaky typ navratovej hodnoty atd)
Název: Re:Dědičnost dnes
Přispěvatel: zboj 30. 01. 2017, 14:07:54
Ovšem nic z výše uvedeného nemění nic na faktu, že objektově orientované programování je trošku něco jiného než Java. A že problémy, které jsou představovány jako problémy OOP, jsou ve skutečnosti problémy Javy. Jinou otázkou je, jak moc jsou ty problémy v praxi palčivé a nakolik jsou spíš akademické. Dalším nemilosrdným faktem je taky skutečnost, že průměrný program v Javě je stále mnohonásobně rychlejší a méně náročnější na paměť než program ve Smalltalku, ale i Objective C.
Smalltalk jsem nikdy neměřil, ale pro ObjC to neplatí ani náhodou, rychlost je srovnatelná (někdy vyšší, protože value types), a paměťově náročnější je Java v podstatě vždy (pokud se teda nepoužije ObjC s GC, ale ten už ani Xcode neumí použít a v macOS už taky ani nejsou příslušné knihovny). Zrovna nízká náročnost na paměť je důvodem, proč Apple zahodil svůj celkem pokročilý GC a nasadil statickou analýzu (ARC).
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 14:10:29
Spíše jestli to nechápeš špatně ty. Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali. Neříkám, že musejí být lepší než ty, ale podle těch tvých hlášek tady pochybuju, že bys uměl programovat. Pokud máš problém jen s tím, že Java je OOP, tak je na čase si to tu pro tu debatu trochu změnit.

Takže ještě jednou, proč se používá skoro na všechno Java, když je tak špatná? Dyť by ti podnikatelé raději mohli ušetřit a prodávat luxusní věci, ne? Neříkám, že je úžasná na všechno, ale ty máš určitě hromadu lepších přístupů, které plno problémů odstraní. A nebo jsi jen nic pořádného nedělal, nevím.


OK, dík za info. Těžko říct. Mně je v podstatě jedno, jak budeme Javě říkat. Pro mě je OOP a pro wikipedii také, ale klidně pro účely debaty tomu můžeme říkat jinak. Prostě mám dojem, že tam pořád vidíš něco, co tam není. Nebo to právě mně jen nedocvaklo.

Na druhou stranu nemám moc rád dnešní vývoj, kdy plno lidí umí návrhové vzory a patlání. Většina vzorů je totiž fakt jen opruz navíc, který to spíše zkomplikuje. Jak kdy, ale obecně Java se píše daleko složitější a nedá se pak ani číst. Což je škoda. Takže možná na tom něco bude. Ale pořád nechápu, jak mi dynamičnost může s něčím pomoct. Ano, ztratím plno návrhových vzorů, protože najednou nejsou potřeba a zároveň ztratím skoro vše další. Pak jsem někde na úrovni skriptovacích jazyků jako Bash a Python.

Právě třeba to Ruby je přesně ono. Pro mě je to dynamický shit, který nelze stejně na nic použít. Frčí to hlavně kvůli webům. To je jako PHP. Takže beru, že je populární, ale ne u pořádného vývoje. Proto pořád zůstává otázka, jestli lze tyhle dynamické "hračky" použít na seriozní vývoj.

A jsem rád, že to probíráme, takže to není nic proti nikomu. Možná ale embedded je právě o menších a přesných programech? Tam bych si dovedl představit dynamické typování, protože ta velikost nemusí být tak velká. Ale nevím, třeba je to velké i tak.
Název: Re:Dědičnost dnes
Přispěvatel: ava 30. 01. 2017, 14:17:18
Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D

Budeme radši říkat netypované (protože u zasílání zpráv se nic netypuje/netříduje, alespoň ne na straně odesílatele). Ano, to je původní koncept (důsledky a použití zde byly uvedeny).

Ako sa to vezme, objekt vzdy smalltalku nesie o sebe vedomost, akeho je typu/triedy. Je na programatorovi, ci sa na ten typ spyta (Ci ocakava nejake rozhranie, alebo nejaky typ navratovej hodnoty atd)

Přesně, já taky nejradši rozlišuji typování ve dvou osách - při překladu a při běhu, a tyto úrovně jsou u většiny jazyků nezávislé.

Typování při překladu ("statické typování") - hodnoty se anotují typy, většinou nominálně, tj. napíše se "foo" je Int a "bar" je instance třídy Bar. Anotují se i parametry metod/funkcí. Většinou si typy musí sedět, jinak se program nepřeloží (ne nutně, existuje i optional nebo pluggable typing).

Hodnoty znají své typy při běhu - "dynamické typování" - pošlu objektu zprávu (= zavolám metodu), a on se polymorfně zachová podle toho, jakého konkrétního typu je.

A teď nezávislost obou typování:

Assembler (víceméně) nemá ani jedno, registr se dá interpretovat jako číslo, znak, ukazatel do paměti, ....

C-čko/C++ bez RTTI mají statické, ale ne dynamické typování, za překladu anotuji hodnoty typy, ale za běhu už z pointerů nic nezjistím, můžu si přetypovat cokoliv na něco jiného.

Python/Smalltalk/... mají dynamické typy, ale za překladu nic neanotuji, za běhu se ale mohu ptát, jaké třídy jsou objekty instance, posílat jim libovolné zprávy a ony na ně správně reagují

Java, Scala atp.. mají i statické typování, i dynamické.
Název: Re:Dědičnost dnes
Přispěvatel: BoneFlute 30. 01. 2017, 14:43:12
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad.

Měl jsem za to, že v Haskellu (při troše fantazie) je všechno funkce, nic nejsou data. I takový symbol 42 je jen nulární funkce.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 14:47:12
....Ale pořád nechápu, jak mi dynamičnost může s něčím pomoct. Ano, ztratím plno návrhových vzorů, protože najednou nejsou potřeba a zároveň ztratím skoro vše další. Pak jsem někde na úrovni skriptovacích jazyků jako Bash a Python.

Navrhove vzory nezavisia od toho, ma jazyk dynamicku, alebo staticku typovu kontrolu. Vo vzoroch sa predpokladaju len nejake vztahy objektov a urcite rozhranie, ktore nemusi byt ani explicitne zadefinovane. Skor nez o typoch su vzory o roliach.
Název: Re:Dědičnost dnes
Přispěvatel: zboj 30. 01. 2017, 14:48:44
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad.

Měl jsem za to, že v Haskellu (při troše fantazie) je všechno funkce, nic nejsou data. I takový symbol 42 je jen nulární funkce.

Teoreticky jo, každá konstanta je funkce. Ovšem každé číslo je čistě matematicky taky tenzor a stejně z něj v IT Integer nebo Float nedědí. Proto spíše než dědičnost - abychom se vrátili k tématu vlákna - je lepší používat hierarchii rozhraní, pak můžu Integer nebo Float modelovat třeba jako speciální případ komplexního čísla, což by sice dědičností šlo taky, ale má to v klasicky pojatém OOP dost negativních důsledků.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 14:51:37
....Ale pořád nechápu, jak mi dynamičnost může s něčím pomoct. Ano, ztratím plno návrhových vzorů, protože najednou nejsou potřeba a zároveň ztratím skoro vše další. Pak jsem někde na úrovni skriptovacích jazyků jako Bash a Python.

Navrhove vzory nezavisia od toho, ma jazyk dynamicku, alebo staticku typovu kontrolu. Vo vzoroch sa predpokladaju len nejake vztahy objektov a urcite rozhranie, ktore nemusi byt ani explicitne zadefinovane. Skor nez o typoch su vzory o roliach.

To asi jo, ale když Python nemá rozhraní, tak asi třetina vzorů najednou není potřeba, protože to tam naprasím napřímo :D Zase takový singleton skoro ani neudělám, protože to jednoduše nejde. Ale jsme přece dospělí, tak na co singleton...
Název: Re:Dědičnost dnes
Přispěvatel: Honza 30. 01. 2017, 15:12:49
To asi jo, ale když Python nemá rozhraní, tak asi třetina vzorů najednou není potřeba, protože to tam naprasím napřímo :D Zase takový singleton skoro ani neudělám, protože to jednoduše nejde. Ale jsme přece dospělí, tak na co singleton...
Tak zrovna Singleton je legitimní návrhový vzor. Ale zrovna v Javě, pokud udělám private konstruktor, tak sice zajistím pouze jednu instanci, ale nemůžu to vůbec testovat. Na to bych potřeboval instanci ještě jednu pro testy.
No nevím, tvrdit o tom, že je právě tohle v Javě výhoda... Vždycky přece můžu mít přece více instancí, a stále to bude dle vzoru Singleton. Ale vždycky se najde někdo, kdo bude tvrdit, že bez private konstruktoru v Javě to není Singleton...
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 15:15:56
OMG, singleton je v Javě antipattern. Ale to nebyl point ;D Šlo jen o to, že ty běžné OOP návrhové vzory se úplně pro dynamické jazyky nehodí, protože to nedává smysl, když je vše dynamické a my dospělí.
Název: Re:Dědičnost dnes
Přispěvatel: Kiwi 30. 01. 2017, 15:17:19
Spíše jestli to nechápeš špatně ty. Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali. Neříkám, že musejí být lepší než ty, ale podle těch tvých hlášek tady pochybuju, že bys uměl programovat. Pokud máš problém jen s tím, že Java je OOP, tak je na čase si to tu pro tu debatu trochu změnit.

Takže ještě jednou, proč se používá skoro na všechno Java, když je tak špatná? Dyť by ti podnikatelé raději mohli ušetřit a prodávat luxusní věci, ne? Neříkám, že je úžasná na všechno, ale ty máš určitě hromadu lepších přístupů, které plno problémů odstraní. A nebo jsi jen nic pořádného nedělal, nevím.


Na druhou stranu nemám moc rád dnešní vývoj, kdy plno lidí umí návrhové vzory a patlání. Většina vzorů je totiž fakt jen opruz navíc, který to spíše zkomplikuje. Jak kdy, ale obecně Java se píše daleko složitější a nedá se pak ani číst. Což je škoda. Takže možná na tom něco bude.

Přesně stejný dojem to budí i ve mně.

Právě třeba to Ruby je přesně ono. Pro mě je to dynamický shit, který nelze stejně na nic použít. Frčí to hlavně kvůli webům. To je jako PHP. Takže beru, že je populární, ale ne u pořádného vývoje. Proto pořád zůstává otázka, jestli lze tyhle dynamické "hračky" použít na seriozní vývoj.

Stáhni si Pharo, k tomu třeba pdf-knížku Pharo by Example a ve volných chvílích si s tím hraj. Čistě jen pro zažití, že to OOP se dá dělat i trochu jinak, než je člověk zvyklý. Ne snad kvůli tomu, abys pak dělal v něčem jiném, ale ono to člověka ovlivní. Pak najednou sám sebe přistihne, že by spoustu věcí i v té Javě dělal trochu jinak než vídá, nebo dokonce jinak, než mu radí knížky. Mirek už ti tu doporučoval Elixir, s tím si taky tak můžeš hrát. Ne snad kvůli zahození Javy, ale k tomu, aby člověk uzřel, že na jednu a tu samou věc, jeden problém, se dá dívat z různých stran a že různé problémy vypadají z různých stran různě příjemně/nepříjemně. A podle toho se pak umět lépe rozhodnout, z jaké strany bude nejvhodnější do toho ty vidle vrazit. Připadá mi to mnohem užitečnější než všelijaké ty knížky "Jak se naučit psát super dokonalý kód za 30 dní" apod.

A jsem rád, že to probíráme, takže to není nic proti nikomu. Možná ale embedded je právě o menších a přesných programech? Tam bych si dovedl představit dynamické typování, protože ta velikost nemusí být tak velká. Ale nevím, třeba je to velké i tak.

Bývají to i docela rozsáhlé věci. V této branži ale spíš platí opak - čím méně dynamické, tím lépe, statická typová kontrola, kde to jen jde, mít stále na paměti omezené prostředky, časové nároky více či méně realtimové... Přestože objektové programování tady dostává reálný význam jako málo kde jinde, protože ty objekty budou často představovat opravdu objekty reálného světa, ty černé krabičky jsou opravdu nějaké krabičky, s kterými se komunikuje po nějakých drátech, tak z praktického hlediska se tu "OOP" (i to C++kové, natož něco dynamického) spíše nadužívá. Když neustále hrozí hláška linkeru "out of memory", tak se s tím moc rozumně objektově programovat nedá.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 15:47:30
Jasný, Elixír už mám na seznamu. Mám rád experimenty, proto jsem zkoušel třeba Scalu a čisté FP jazyky. Proč ne, jen zatím nikam nepřecházím. Ono tyhle teoretické debaty většinou nikdo moc rád nemá, takže souhlasím, že je to daleko lepší než jasné kuchařky. Každý by rád měl jasná řešení, která se jen naučí. Tak to ale nefunguje.

Hmmm, tak těžko říct. Mám rád vše statické, protože jinak se mi tam vkrádají další problémy, které mě nezajímají. Typicky co poslat někomu. Takhle se podívám a vím. Jasně, omezuje mě to, ale to je právě ta výhoda.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 16:02:19
OMG, singleton je v Javě antipattern. Ale to nebyl point ;D Šlo jen o to, že ty běžné OOP návrhové vzory se úplně pro dynamické jazyky nehodí, protože to nedává smysl, když je vše dynamické a my dospělí.

Singleton ide v pythone spravit. A to, ze to nedava v dynamickych jazykoch zmysel, je dufam ironia ;)

Singleton nie je antipattern, je to velmi sikovny pattern.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 16:09:59
Jde, asi tak jako tam jde mít private přístup a nebo typy. Proč? Většina jich tam nedává smysl, protože jsou právě na to, abys nějak statické typy vhodně postavil.

Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.
Název: Re:Dědičnost dnes
Přispěvatel: Honza 30. 01. 2017, 16:23:45
Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.
Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.
Název: Re:Dědičnost dnes
Přispěvatel: javaman () 30. 01. 2017, 16:27:25
Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.
Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

Přesně tak. Jde o všechny varianty. Vtipné je, že většina lidí, když se ptá na pohovorech, ani neumí všechny a zároveň umí jen ty nepoužitelné. Ale pořád se na to ptají :D Alespoň člověk ví, co tam bude za lidi.
Název: Re:Dědičnost dnes
Přispěvatel: balki 30. 01. 2017, 17:08:23
Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.
Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

Přesně tak. Jde o všechny varianty. Vtipné je, že většina lidí, když se ptá na pohovorech, ani neumí všechny a zároveň umí jen ty nepoužitelné. Ale pořád se na to ptají :D Alespoň člověk ví, co tam bude za lidi.

Singleton sa nezvykne pouzivat, ak je k dispozicii dependency injection framework. Ale i