Dědičnost dnes

[SB]

K čemu propánajána strom? Mám dva listy - v jednom je seznam vrcholů, ve druhém seznam hran - tj dvojic (from,to). Právě proto, že jsou data imutabilní a identitu není potřeba řešit, můžu mít klidně v obou listech nejenom nějaká idéčka (nepřímé reference), ale i přímé reference, nebo klidně i "instance" samotné (protože nemají identitu, stejné hodnoty mají z definice tutéž identitu).

Nepoužívejte zde prosím anglický název pro seznam, je v tom pak bordel...

...a v těch seznamech budete hledat a spojovat je, ne? Tak tohle rychlé nebude. Připomíná to relační model. S jednoduchostí, přirozeností (OOP je grafové z podstaty) a elegancí objektového modelu si to nezadá.

[Reklama]

[Mirek Prýmek]

Kód [Vybrat] Rozbalit


a = ...
b = ...
nodes = [a,b]
edges = [(a,b),(b,a)]


Sorry, tady jsem se upsal tím přepnutím z Pythonu, v Elixiru jsou tuples správně takhle:

Kód [Vybrat] Rozbalit


[{a,b},{b,a}]


Nepoužívejte zde prosím anglický název pro seznam, je v tom pak bordel...

Omlouvám se, došlo mi to až po odeslání příspěvku, že vlastně "list" taky něco znamená česky )

...a v těch seznamech budete hledat a spojovat je, ne? Tak tohle rychlé nebude. Připomíná to relační model. S jednoduchostí, přirozeností (OOP je grafové z podstaty) a elegancí objektového modelu si to nezadá.

No a to právě není pravda, protože přesně to samé můžu říct opačně: aha, takže mám jenom odkazy v jednotlivých objektech. A pokud budu chtít počet všech hran, tak to budu celé procházet a značit si, kde už jsem byl?!

[SB]

Je to podobne elegantni jako to GOTO. Problem nastane, jakmile si uvedomis, ze pokud mas takovou sit vzajemnych odkazu, musis nejak resit updatovani vsech vadnych pointeru, a jak je najdes, aniz by neco melo prehled o tom, co kam ukazuje? Proste pokud datova struktura neni strom, existuji tam extra naklady na praci s ni, ktere opomijis.

Teď ještě, co jsou to ty "vadné pointery".

[gll]

Pokud chci u té první reprezentace získat seznam všech vrcholů, musím je nejenom všechny postupně projít (složitost n), ale navíc musím ještě kontrolovat, které už jsem navštívil (protože cykly).

Nerozumíme si. Mluvil jsem o reprezentaci spojovými seznamy v FP jazyku. V pythonovském listu by šlo vynechat ty odkazy na předchůdce, ale hlavně v pythonu je podobná reprezentace nesmysl.

v1 = ('id1', None, None)

v2 = ('id2', v1 ,(v1, 2, None))

v3 = ('id3', v2, (v1, 1, (v2, 3, None)))

odkazy na předchůdce jsou odkazy v listu, ne v grafu. Dá se takto reprezentovat jen DAG (acyklický, orientovaný graf).

Při procházení vrcholů prostě nebudete odbočovat na seznamy hran. Projdete jen list vrcholů.

https://en.wikipedia.org/wiki/Adjacency_list

Neplést prosím střední a maximální časovou složitost. Vyhledávání s maximální složitostí (o té jsem psal) O(1) neexistuje. Optimální složitost pro nejhorší případ je O(log n).

viz http://stackoverflow.com/a/9214594/3150343

neúmyslně se vám nepovede vložit několik kolidujících klíčů.

opravdovou hashmapu byste musel kopírovat při každé změně, pokud má být immutable. Právě proto se v FP jazycích používají stromy.

Nemusí. Runtime ví, jestli se do mapy zapisuje, a může klidně použít jakoukoli implementaci.

to je možné, stále zde zůstává problém s neměnností.

[SB]

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

Musim ocenit, ze viete googlit ale:

• Nevola sa to triedne, ale objektovo-orientovane programovanie. Je to objektoch, triedy nestastne vymyslel Kay.


• Testovanie singleton neztazuje, staci si nastavit pri testovani singleton. Skobinujem ho so vzorom strategy a voila, da sa to menit za hocico! Brutalne tazka robota. Rozne mock objekty a  netrivialne zavislosti testovanie komplikuju viac. Btw unit testy ako su dnes vymyslene nie su objektove.


• Viac konfigurakov v jednej aplikacii? To je naco dobre?

To jakože implementace sériového portu se bude měnit podle toho, kolik jich zrovna v počítači budete mít, případně u koho tu aplikaci spustíte?

To jste si trochu naběhnul - zrovna smalltalkové třídy jsou implementované jako objekty, takže samotný VM koncept třídy nezná, pak funkcionalitu je možno rovnocenně umístit na požadovanou úroveň hierarchie objektů dle požadavku, např. do "metatříd". Úžasně vymyšlené, co?

Každý konfigurák může nastavovat něco jiného, případně může být nějaký obecnější, sdílený, v conf.d... Podle vkusu každého soudruha.

[Reklama]

[balki]

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

Musim ocenit, ze viete googlit ale:

• Nevola sa to triedne, ale objektovo-orientovane programovanie. Je to objektoch, triedy nestastne vymyslel Kay.


• Testovanie singleton neztazuje, staci si nastavit pri testovani singleton. Skobinujem ho so vzorom strategy a voila, da sa to menit za hocico! Brutalne tazka robota. Rozne mock objekty a  netrivialne zavislosti testovanie komplikuju viac. Btw unit testy ako su dnes vymyslene nie su objektove.


• Viac konfigurakov v jednej aplikacii? To je naco dobre?

To jakože implementace sériového portu se bude měnit podle toho, kolik jich zrovna v počítači budete mít, případně u koho tu aplikaci spustíte?

To jste si trochu naběhnul - zrovna smalltalkové třídy jsou implementované jako objekty, takže samotný VM koncept třídy nezná, pak funkcionalitu je možno rovnocenně umístit na požadovanou úroveň hierarchie objektů dle požadavku, např. do "metatříd". Úžasně vymyšlené, co?

Každý konfigurák může nastavovat něco jiného, případně může být nějaký obecnější, sdílený, v conf.d... Podle vkusu každého soudruha.

Ok, kazdy konfigurak nastavi nieco ine, ale 10 kopii tych istych parametrov mat v systeme je neziaduce. Najma u enterprise aplikacii, kde sa zvyknu menit parametre za chodu.

Otazka, naco su potom triedy, ked vsetko je objekt? Nestacilo by potom triedy zrusit? Aj meta triedy aj meta-meta triedy aj meta-meta-meta .... ?

[SB]

...a v těch seznamech budete hledat a spojovat je, ne? Tak tohle rychlé nebude. Připomíná to relační model. S jednoduchostí, přirozeností (OOP je grafové z podstaty) a elegancí objektového modelu si to nezadá.

No a to právě není pravda, protože přesně to samé můžu říct opačně: aha, takže mám jenom odkazy v jednotlivých objektech. A pokud budu chtít počet všech hran, tak to budu celé procházet a značit si, kde už jsem byl?!

V OOP není problém (velikostní, rychlostní ani přehlednostní) ke grafu držet navíc seznam hran či uzlů (dle každého soudruha). Naopak si myslím, že toto je dobrým příkladem, že OOP je pro grafy vhodnější než FP (což ale není žádným překvapením).

[balki]

To jakože implementace sériového portu se bude měnit podle toho, kolik jich zrovna v počítači budete mít, případně u koho tu aplikaci spustíte?

Toto je vasa fabulacia.

[BoneFlute]

IMHO ale nejlepsi je trochu se naucit Haskell. Cloveka to trochu hodi do vody, a je z toho pomerne zrejme, proc se v FP veci delaji jak se delaji; v jinych jazycich, ktere jenom prejimaji prvky FP (treba Scala nebo Java) mohou nektere veci vypadat podivne. No a kdyz ziskas trochu zkusenost, uvidis sam, jak se ty veci, na ktere se ptas, daji realizovat pres skladani funkci, bude ti to proste pripadat prirozene a naopak pristup pres tridy a interfacy uvidis jako zbytecne tezkopadny. (Bohuzel se to tezko sdeluje..)

Takové nešťastně řečené. Haskell má třídy (říká jim typy) a interface (říká jim třídy). A je to dost důležitý a užívaný koncept. Snad ten nejdůležitější v Haskellu, který jej odlišuje od ostatních FP jazyků. Ne nadarmo se používá úslový: "následuj typy".

[lopata]

Vyhledávání s maximální složitostí (o té jsem psal) O(1) neexistuje. Optimální složitost pro nejhorší případ je O(log n).

Vyhledávání s maximální složitostí O(1) existuje, jmenuje se to perfect hashing: https://en.wikipedia.org/wiki/Perfect_hash_function
Data ale musí splňovat nějaké předpoklady (je potřeba dopředu alespoň zhruba vědět, kolik jich bude). Zkonstruovat perfektní hashovací funkci je docela časově náročné, ale potom to vyhledává s maximální složitostí O(1).

[Mirek Prýmek]

...

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

Jestli to, že v některých situacích jsou imutabilní reprezentace míň efektivní než mutabilní, tak jsem už několikrát zopakoval, že s tím nemám sebemenší problém, to je jasné.

Jestli se snažíte dokázat, že mutabilní reprezentace jsou vždy efektivnější, tak to dokazujete špatně (nevyplývá to z toho, co píšete).

V OOP není problém (velikostní, rychlostní ani přehlednostní) ke grafu držet navíc seznam hran či uzlů (dle každého soudruha).

A v FP zas GC nemusí řešit kruhové závislosti, čili může být výrazně efektivnější. Takže co z toho plyne?

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

[Mirek Prýmek]

Data ale musí splňovat nějaké předpoklady

Je fajn, že víme, že existuje případ, o kterém se nebavíme, který má jiné vlastnosti

[lopata]

Je fajn, že víme, že existuje případ, o kterém se nebavíme, který má jiné vlastnosti

Jen vyvracím nepravdivé tvrzení, že vyhledávání s maximální složitostí O(1) neexistuje .

[SB]

Ok, kazdy konfigurak nastavi nieco ine, ale 10 kopii tych istych parametrov mat v systeme je neziaduce. Najma u enterprise aplikacii, kde sa zvyknu menit parametre za chodu.

Otazka, naco su potom triedy, ked vsetko je objekt? Nestacilo by potom triedy zrusit? Aj meta triedy aj meta-meta triedy aj meta-meta-meta .... ?

A co hierarchie parametrů, kde každý parametr má okamžitou hodnotu z nejnižší nalezené úrovně (nejvyšší váha)?

Tak si nahraďte název "třída" názvem "vzor". A vytváření objektů dle vzoru je užitečnou funkcionalitou. Nikde není psáno, že samy obecnější vzory nemůžou vytvářet speciálnější vzory (= systém metatříd, tříd a objektů).

[Mirek Prýmek]

Jen vyvracím nepravdivé tvrzení, že vyhledávání s maximální složitostí O(1) neexistuje .

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

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

Kód [Vybrat] Rozbalit


def search(_,_), do: nil

...ovšem za předpokladu, že se bavíme jenom o prázdných seznamech.