Jen pro upřesnění, ne, že bych měl JSON nějak zvlášť rád:
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.
Výraz nedefinované mi přijde krapet silné vyjádření. Každopádně v JSON je číslo definováno typem number. Který není ani Int, ani Float. Takže podobně jako když v Haskellu rozlišuju, čím budu reprezentovat JSON typ string - zda použiju typ String, typ Text, nebo ByteString; podobně i v případě JSON typu numeric musím přemýšlet čím ho budu v Haskellu reprezentovat. Protože s Intem si nevystačím (když tam chci ukládat Float, což jde).
Pokud bude ten parser rozumný, tak:
decode "1" -> 1.0 :: Float
decode "1.0" -> 1.0 :: Float
encode 1.0 :: Float -> "1.0" -- ale může i "1"
encode 1 :: Int -> "1.0" -- ale může i "1"
encode (9007199254740991+100) :: Int -> "\"9007199254741091\"" -- nebo spíše error "příliš velké číslo"
decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen
Takže můžem nadávat na JSON, že je to debilně triviální jazyk. Můžem nadávat, že nám v něm schází to či ono. Ale spousta výtek jde spíše na vrub parserům v tom kterém jazyce.
334 Odpovědí
39864 Zhlédnutí