Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
a) Dao (https://github.com/daokoder/dao ) - ma "vsechno", umi "vsechno", je moderni, je navykovy, je mene znamy, dokumentace ma mouchy
Jinak je samozřejmě k dispozici for, for in a for of.
1. monkey patching. Nevidím problém v možnosti přidat nějakou metodu jako takové. Ale v tom, že bez varování mohu přepisovat existující, to mi přijde nešikovné.
2. jazyk je to strašně ukecanej, na to, že toho zase tolik neumí
3. žádná podpora pro zapouzdření. Zapouzdřenost ala Python by mi stačila.
4. nejednotnost - třeba jazyk Lua má pro "nic" jen jednu hodnotu. A můžeš na ni normálně "šahat", chybu ti vyhodí tepreve nil of nil. Javascript má undefined, null, '', 0, false. Vytváření objektu jde taky dělat na několik způsobů, včetně pravěkého "new".
5. absence foreach mě furt nutila přecházet do transpilerů
6. má typy ale nemá statické typování - prvé bez druhého podle mého nemá vůbec žádný smysl. Buď ať je to dynamický jazyk bez typů (příklad Lua, Erlang), nebo staticky typovaný.
1. Ide to. Object.defineProperty()
2. Nepodstatné
3. Isteže nemá, je postavený na inom princípe, zrovnávaš hrušky s jablkami.
4. Nepodstatné, stačí vedieť čo robíš.
5. Má foreach.
6. Len tvoj názor. Ide použiť tak ako je, to nie je praktický problém.
JavaScript je ve sve podstate dokonaly skoro od pocatku. Vsechno je objekt, event driven, jednoducha syntax a uspokojiva sada zakladnich knihoven, proste klasicky computational complete scriptovaci jazyk 3.5te generace = udelas v nem vse. Novejsi varianty od ES6+ nebo TS jsou povetsinou sugar syntax nadstavbou nad dokonalym zakladem ale taky pridavaji FP ficury co muzeme nalezt u jinych jazyku (treba iteratory, generatory, nove operatory atd.)
Co mu lze vytknout je v podstate to, ze mnoho odpousti a tam kde by jiny jazyk uz bezmocne rval tak JS se porad este snazi nepadnout. I kdyz je jednoduchy tak neni moc pro zacatecniky, treba operator + ma dvoji vyznam (na kterem je zalozena drtiva vetsina JS vtipku a snazi se autocastnout cokoliv aby nepadnul).
Ta C-like syntax je zaroven zdroj potizi pro prebehlivce z jinych jazyku, protoze si mysli, ze kdyz umi C ci Javu tak daji JS levou zadni a pak rvou nesmysly po forach misto toho aby si koukli manual a naucili se JS pouzivat spravne. Prasarny se daji delat v kazdem jazyku, naucte se ho poradne a nedelejte je, pak bude JS dobry sluha.
Casto se mu vytyka matika ale je to standardni implementace jako u spousty jinych jazyku a komu je to malo ma hafo knihoven pro presnejsi matiku.
Sila JS je taky v tom, ze vzhledem na chudost zabudovanych knihoven vzniklo milion frameworku a nadstaveb takze je z ceho vybirat a nemusite vynalezat kolo. Typicky treba utilitky pro funkcionalni programovani jako underscore nebo lodash.
Suma sumarum JS dnes vladne webu, vyhrava na frontendu (Electron, desktop managery) a pomalu si podmanuje backend (nodejs). Milovnici starych "dobrych" casu a jazykou mohou spkripat zuby, ale je to tak, zitra bude vsechno v JS resp. jeho novejsich iteracich.
Python ... mají mocnější typový systém než Java/C#, ale slouží jen ke kontrole.Ani náhodou!
Když už to děláš v shellu, vyzkoušej příkaz sqlite3, který ti umožní persistovat data v jednom souboru podle nějakého klíče.
Pokud je to moc komplikované, můžeš zkusit další jednoduché souborové databáze DB4, Tokyo Cabinet, TDB apod.
Přičemž kolekce není objektem? DataMapper nemapuje objekty? ActiveRecord nemapuje objekty? Problém ArctiveRecordu přeci není v mapování objektů, či kolekcí. A výhoda DataMapperu není v tom, že je to modernější. Věci mají svůj důvod a význam.CitaceData mapper Podle tohoto vzoru neobsahuje doménový objekt žádné CRUD nebo vyhledávací operace a o vytváření, úpravu a mazání doménových objektů z databáze se stará oddělený (mapovací) objekt. Doménový objekt je tedy zcela nezávislý na databázi. Zatímco mapovací objekt má přístup jak k doménovému objektu, tak k databázovému systému. Výhodou tohoto vzoru je právě nezávislost doménového objektu na datovém modelu, kdy je veškerá zodpovědnost za persistenci přesunuta na mapovací objekt.
https://cs.wikipedia.org/wiki/Data_Mapper
Ve výsledku mi Tvůj příspěvek nedává moc smysl (netuším, jak jsi to myslel).
Doménovým objektem je jednoduše kolekce.
Zdravim,
mam 5 hodnot, ktere prubezne potrebuji aktualizovat, zobrazovat. Nejlepe podle klic->hodnota. Existuje nejaka vhodna metoda na misto zakladani databaze?
Co má s OOP společného mít data v kolekcích a ne v objektech (sic!) a ActiveRecord či DataMapper? Zřejmě jen jel volnou asociaci, stejně jako ty.OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.
Co s tím má společného ORM?
Takže buďto získám mechanismus omezeně kontrolující správnost výpočtu - otázkou je, zda to stačí, nebo zcela spolehlivě ověřím výpočet, ale samotná definice typu bude nutně stejně složitá jako samotný výpočet, takže můžu udělat tu samou chybu 2x. Závěr: Obecně neexistuje žádný magický mechanismus, který by dokázal (aťto v typu či jinde) rozhodnout, zda je můj výpočet správný.
na to obvykle slouží otevření a uzavření závorek).Použití závorek pro určení bloku považuju za zjedudušení parseru a historický relikt. Odsazování považuji za mnohem čitelnější a praktičtější. Ale samozřejmě existují výjimky a je dobré, když je možné ty závorky použít. Což třeba Haskell i Python splňují.
jednotkové testy nejsou potřeba máte-li kvalitní typový systém.Typem jde vyjádřít jakákoliv vyčíslitelná vlastnost. Testy (nejen jednotkové) mají tu nevýhodu, že mohou prokázat přítomnost bugů, ale nikdy jejich absenci. Typový systém dokáže prokázat korektnost (absenci bugů).
Jinými slovy: v porovnání s SQL máte v GraphQL jen prosté sloupečky a (outer) joiny. Žádný WHERE nebo ORDER (natož pak GROUP BY).
Ano, v jazyku GraphQL pre to neexistuje specificky konstrukt.., ale v zavislosti od toho, ku akej databaze sa pripajas, si od nej mozes vediet vypytat vyfiltrovane, zoradene, alebo agregovane data...,
niektori ludia by povedali, ze v tom je krasa graphql, ze je take jednoduche.., ini ludia sa naucia graphql, lebo musia, a potom su zhrozeni, ked ho chcu pouzit s niecim inym
GraphQL není nic jako "SQL pro grafové databáze" a celkově vůbec nic srovnatelného s SQL.
Mozna autor myslel SPARQL, to je tusim pro grafove databaze. S GraphQL se mi to taky plete.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
