Kniha Objektové programování od Čady

[Bufik]

A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil?

Budes, protoze jsi zvolil JSON kde typovost neni primarni zalezitost (jako obecne v JS, to jen nejavascriptiste porad neco melou o typech a resej dest castovacich funkci, kdyz chces udelat neco tak trivialniho jako "5" * 5 ). Kdyz jsou u tebe typy smysl vesmiru tak pouzij XML a <item name="smysl vesmiru" typ="int">42</item>...
Proste places na nespravnem hrobe a pouzivas nespravny lopaty :-)

[Reklama]

[Kit]

Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.

Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?

A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...

Když dáš json_encode($object), tak v něm budeš mít přesně to, co do něj potřebuješ dostat, včetně kolekcí - tedy i map a stromů. Typy samozřejmě také.

[gll]

Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.

Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?

A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...

Když dáš json_encode($object), tak v něm budeš mít přesně to, co do něj potřebuješ dostat, včetně kolekcí - tedy i map a stromů. Typy samozřejmě také.

Zrovna v případě serializace objektů val == json_decode(json_encode(val)) neplatí. Deserializací získáš pole a ne objekt.

[Mirek Prýmek]

Když dekódujete číslo s desetiným místem, logicky chcete float. Když číslo bez desetiného místa, tak vám může být jedno co dostanete.

Ne a ne. Jestli se JSON "3.0" vyparsuje jako int nebo float je nedefinované. Naopak zakódovat int 3 jako 3.0 je plně legitimní. Z čeho a jak plyne, že "logicky chci float", to fakt nevím. Od serializačního formátu především chci, abych z něj dostal to, co jsem do něj dal. Pokud to neplatí ani pro základní věc jako číslo, je to prostě debilní serializační formát a není o čem diskutovat.

JSON se rozšířil, protože je jednoduchý. Když vám nevyhovuje, alternativy existují.

Netvrdil jsem, že neexistují.

Kdyz jsou u tebe typy smysl vesmiru

Ne nejsou. Pro mě je smyslem serializace, aby z ní lezlo to, co do ní dám, a nemusel jsem kolem toho dělat milion opiček.

Jaký je rozdíl mezi atomem a stringem?

Asi tak stejný jako mezi stringem a intem.

[Kit]

Když dáš json_encode($object), tak v něm budeš mít přesně to, co do něj potřebuješ dostat, včetně kolekcí - tedy i map a stromů. Typy samozřejmě také.

Zrovna v případě serializace objektů val == json_decode(json_encode(val)) neplatí. Deserializací získáš pole a ne objekt.

json_decode(json_encode(val), true) to řeší.

Zapomínáš, že výsledný JSON není určen pro PHP, ale pro Javascript, kterému je to jedno. Pokud potřebuji serializovat pro PHP, použiji funkci serialize(), který však není určen pro Javascript.

JSON prostě není ideální formát, ale je velmi výhodný pro spolupráci s Javascriptem. Z bezpečnostních důvodů není ani vhodné, pokud by se objekt předával do PHP kompletní. Je lepší, pokud se do PHP předává v podobě datového stromu.

[Reklama]

[Youda]

Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.

O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.

Od toho existuje view.
ORM mapper je omezeny na tupy CRUD. Treba Oracle MERGE s tim nezavolam.
Osobne nechapu tu nechut lidi kolem javy se naucit rozumne SQL, vzdyt je to tak jednoducha zalezitost.
Je jednodussi se naucit zaklady Oracle PLSQL nez se naucit BEZPECNE delat v Hibernate.

[gll]

Jaký je rozdíl mezi atomem a stringem?

Asi tak stejný jako mezi stringem a intem.

Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?

[Mirek Prýmek]

Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?

Pokud by ty immutable stringy byly uložené v paměti jenom jednou a vždycky a všude by byly používány jenom reference (včetně toho, že když vytvořím nový string, podívám se, jestli už ho v paměti nemám), tak by to bylo prakticky totéž. Atom je v Erlangu reference do "atoms table" - velikost 1 slovo.

Nicméně v tom kontextu, o kterém se bavíme, jde o to, že to typově není ani string ani int - tj. potřebuju explicitně vědět, že tuhle hodnotu mám načíst jako atom. Rozumné serializační formáty umí uživatelské typy, takže to tam není problém snadno a čistě doplnit (pokud formát sám o sobě atomy neumí, což většinou neumí). JSON nic takového nemá. Musím si udělat vlastní proprietární formát nad formátem, úplně zbytečně.

[Kit]

Od toho existuje view.
ORM mapper je omezeny na tupy CRUD. Treba Oracle MERGE s tim nezavolam.
Osobne nechapu tu nechut lidi kolem javy se naucit rozumne SQL, vzdyt je to tak jednoducha zalezitost.
Je jednodussi se naucit zaklady Oracle PLSQL nez se naucit BEZPECNE delat v Hibernate.

Mám podezření, že lidé kolem Javy (i jiných jazyků) jsou přesvědčeni, že to naprogramují lépe a kvalitněji, než kdyby to udělali v nativním SQL. Ještě horší to bývá s vloženými procedurami, funkcemi a triggery. Někdo před nimi na tom pohořel a teď jim vnucuje do hlav, že tyto schopnosti databází jsou špatné.

[UF]

Jaký je rozdíl mezi atomem a stringem?

Asi tak stejný jako mezi stringem a intem.

Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?

tak trebas to ze je to neco uplne jinyho

[JS]

Osobne nechapu tu nechut lidi kolem javy se naucit rozumne SQL, vzdyt je to tak jednoducha zalezitost.
Je jednodussi se naucit zaklady Oracle PLSQL nez se naucit BEZPECNE delat v Hibernate.

Je to jiny jazyk s jinou filozofii, proto ta nechut. Ja jsem podobne snazil par Javistum vysvetlit, at si k pochopeni FP nastuduji Haskell spise nez Scalu nebo Java 8 streamy, ale taky jsem vesmes nepochodil. :-)

[gll]

Jaký je rozdíl mezi atomem a stringem?

Asi tak stejný jako mezi stringem a intem.

Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?

tak trebas to ze je to neco uplne jinyho

V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?

[gll]

Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?

Pokud by ty immutable stringy byly uložené v paměti jenom jednou a vždycky a všude by byly používány jenom reference (včetně toho, že když vytvořím nový string, podívám se, jestli už ho v paměti nemám), tak by to bylo prakticky totéž. Atom je v Erlangu reference do "atoms table" - velikost 1 slovo.

přesně tak Python ukládá všechny hodnoty. Nejen stringy, ale například i tuple.

[Mirek Prýmek]

V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?

To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.

[SB]

O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

Ale to je přece přímým důsledkem skutečnosti, že podstaty objektů a relací jsou natolik rozdílné, že převody mezi nimi jsou složité. RDB se na objekty nehodí, MNOHEM vhodnější pro objekty jsou dokumentové DB.