|
Because it's unneeded in a data format designed for data interchange.
|
#
?
May 29, 2012 14:44
|
|
|
|
| # ? May 21, 2024 06:28 |
|
|
Golbez posted:I'm an idiot, so what is bad about this? That he didn't know why he was adding it? It's cargo cult as gently caress to just add in features without having a use case.
|
|
#
?
May 29, 2012 15:28
|
|
|
KaneTW posted:Because it's unneeded in a data format designed for data interchange. I could see it being useful if you were using a number for bitmasks, since JSON is rather readable as it is. (A lot more so than some other interchange formats, that's for sure.) Also, the Russian Wonder brought us a new delivery today. We now have another 3 tables for the three columns on another page. But he listened, now there's a useful jQuery widget that makes adding a HTML link to one of the 37 text fields a little easier! 
|
|
#
?
May 29, 2012 17:53
|
|
|
Why is having a machine-readable way to document data interchange (whether XML schema or the proposed JSON schema) a bad idea? Without this it makes it really difficult to write tools to interact with these APIs, relying on the programmer to read the doc and code it all by hand. I wish I could point a tool to a URL and have it materialize classes matching the JSON data structure, complete with enums for flags, etc. Thats one of the few good things about the WebService/WS way. Just point at the WSDL URL and any modern tool can spit out all the boilerplate easily. My objection to XML is how drat complicated it is, not the idea in general. It does make me wonder... Would an HTTP HELP verb serve such a purpose? Instead of everyone coming up with their own API doc format, could you figure out some way to support it directly? I havent really thought this through so there may be some good reasons against it, but I like the idea of some standard machine-readable way to communicate about APIs and data structures. As an aside, it seems like people who only ever deal with twitter-esque services are the ones who never see the need for anything even a little bit complicated. Not everything in the world is a simple picture upload or blog post, sometimes you have to support really complex things like 850 telephone service orders or student school records that require precision and/or complex amounts of data in complex relationships. Edit: which are a massive bitch to code by hand.
|
|
#
?
May 29, 2012 19:07
|
|
|
The whole point of JSON was to be more lightweight than XML, I'm against anything that is going to signficantly bloat JSON libraries or its underlying structure. That said, just give me JSON + a way to handle binary blob data well. If implementing hexadecimals allows this to happen, so be it. But I guess what I want is just JSON+BSON.
|
|
#
?
May 29, 2012 19:20
|
|
|
Strong Sauce: You could use an array of integer values in decimal notation just as easily as an array of integers in hexadecimal notation- the additional number formats confer no greater expressive power and serve only to make the standard more complex. In the context of having a semi- human-readable text format for data interchange it would probably make the most sense to base64 encode your binary blobs and put them in a JSON string, anyway.
|
|
#
?
May 29, 2012 19:31
|
|
|
Just use XML if you need the complex things that have already been implemented for XML. There's no point in completely reinventing everything just for a simpler syntax when the syntax doesn't even fit your needs.
|
|
#
?
May 29, 2012 19:34
|
|
|
Strong Sauce posted:just give me JSON + a way to handle binary blob data well Can't you just base64 your binary data? E: 
|
|
#
?
May 29, 2012 19:37
|
|
|
What you guys need is MIME.
|
|
#
?
May 29, 2012 20:03
|
|
|
Ender.uNF posted:relying on the programmer to read the doc and code it all by hand This isn't directed at you but seriously it screams  But this is what's wrong with the hacking superstar coder culture these days. Read the loving manual and don't reinvent the loving wheel. There are probably at least a dozen "tools" on github that are supposed to overcome problems that could be solved by actually just "interacting" with your peers. Read the docs your coworkers left you, ask them stuff you don't understand, just make the loving phone call that'll take 10 minutes out of your reddit-browsing-time. Maybe your ego tells you otherwise but you're not above it all just because you friended John E Resig on facebook.
|
|
#
?
May 29, 2012 21:01
|
|
|
Ender.uNF posted:relying on the programmer to read the doc This is btw the main reason why JSON is the best data exchange format.
|
|
#
?
May 29, 2012 21:05
|
|
|
I understand some of the complaint. Writing boilerplate code to parse JSON data structures and construct instances of the types in your language's native type system isn't too fun. A lot of it could be generated, as it's the same mechanized work over and over.
|
|
#
?
May 29, 2012 21:17
|
|
|
Suspicious Dish posted:I understand some of the complaint. Writing boilerplate code to parse JSON data structures and construct instances of the types in your language's native type system isn't too fun. A lot of it could be generated, as it's the same mechanized work over and over. Are you suggesting some sort of automated parsing system? Excellent idea, we could call it a "parser" and put it in the standard library of Literally Every Language.
|
|
#
?
May 29, 2012 21:19
|
|
|
Jonnty posted:Are you suggesting some sort of automated parsing system? Excellent idea, we could call it a "parser" and put it in the standard library of Literally Every Language. That doesn't really solve the problem of going from a JSON file to a filled out C++ object with 15 fields, and then have 8 different classes you need to solve that for. (Of course you could also just read things directly from the dictionaries produced by the parser, but that doesn't solve the problem of validating data, and comes at a risk of worse performance.)
|
|
#
?
May 29, 2012 21:26
|
|
|
xf86enodev posted:This isn't directed at you but seriously it screams You know what would be even better? If we had some kind of automatic tool that could check the data for semantic well-formedness as well as simple syntactic validity. I think I've heard of programming languages that have a "static type checker" that does something similar. We could call it, I don't know, a "schema validator", that sounds like a catchy name. And if we have something like that, maybe we can even have it generate properly typechecked code for going from JSON to data in memory and back again, rather than just shoving everything into a bunch of nested hash tables and then manually writing code to check it for well-formedness! Then again, maybe I'm just being a scrub and real programmers do all of their work in Ruby and spit on the filthy static-typing users who want some kind of pre-runtime error checking whenever they pass in the hall.
|
|
#
?
May 29, 2012 21:29
|
|
|
Jonnty posted:Are you suggesting some sort of automated parsing system? Excellent idea, we could call it a "parser" and put it in the standard library of Literally Every Language. To be fair, I work on android and it'd be super swell if, instead of using Jackson's object mapping, which relies on reflection and the tree model, if I could generate a streaming parser instead. Less memory and reflection overhead. And what about the developer who has read the docs and now has to replicate the parser work across Java (Android), Objective-C (iOS), Python (Desktop), and PHP (unfortunate choice of server)? Not that I'd use it, but having a JSON schema wouldn't be *all* bad in all situations. All good tools are doomed to noob abuse anyways.
|
|
#
?
May 29, 2012 21:30
|
|
|
Anyone use Google Protocol Buffers?
|
|
#
?
May 29, 2012 21:32
|
|
|
Jonnty posted:Are you suggesting some sort of automated parsing system? No.
|
|
#
?
May 29, 2012 21:37
|
|
|
trex eaterofcadrs posted:Anyone use Google Protocol Buffers? Are you sure you meant to post this in Coding Horrors?
|
|
#
?
May 29, 2012 21:44
|
|
|
ToxicFrog posted:Are you sure you meant to post this in Coding Horrors? Yeah you guys are all talking about serialization, and I've never used it professionally so I was just tossing it out there to see if anyone had experience with it, in a horrible manner of course.
|
|
#
?
May 29, 2012 21:47
|
|
|
This thread has gone meta. E: ^ post it in the "small programming questions" thread
|
|
#
?
May 29, 2012 21:48
|
|
|
Have we just invented a JSON ORM?
|
|
#
?
May 29, 2012 22:24
|
|
|
Zombywuf posted:Have we just invented a JSON ORM? No.
|
|
#
?
May 29, 2012 22:27
|
|
|
Thank gently caress for that.
|
|
#
?
May 29, 2012 22:30
|
|
|
Maybe allow base64 encoded strings as literals, saves two bytes from the quotes  Seems like transporting large blobs of binary data might be useful to some people and I can think of one reason why I'd rather transport the raw binary rather than an base64 encoded string but it's a probably a pretty specific use case. Just something I wouldn't mind if they implemented into some future version of JSON. But then it wouldn't be able to use it anyways while we wait for users to stop using older browsers/implementations. Strong Sauce fucked around with this message at 22:47 on May 29, 2012 |
|
#
?
May 29, 2012 22:43
|
|
|
Zombywuf posted:Have we just invented a JSON ORM? Goon project.
|
|
#
?
May 30, 2012 00:19
|
|
|
Strong Sauce posted:Just something I wouldn't mind if they implemented into some future version of JSON. But then it wouldn't be able to use it anyways while we wait for users to stop using older browsers/implementations. Not to pick on you, but: Douglas Crockford posted:JSON has no version number. No revisions to the JSON grammar are anticipated. If something has a 1.0, it will inevitably get a 1.1 and a 2.0, and everything is crap until it is 3.0. JSON is very stable.
|
|
#
?
May 30, 2012 00:24
|
|
|
Internet Janitor posted:Not to pick on you, but: Well like I said, I'm not exactly handling large blobs of data using JSON right now, so there's no real effect on me. I merely stated that I could see that some people would find use in having JSON support a raw binary blob. MongoDB's already taken that idea and implemented it with BSON so Crockford saying that doesn't mean it'll stop people from implementing variations on his original idea.
|
|
#
?
May 30, 2012 00:53
|
|
|
Strong Sauce posted:Well like I said, I'm not exactly handling large blobs of data using JSON right now, so there's no real effect on me. I merely stated that I could see that some people would find use in having JSON support a raw binary blob. MongoDB's already taken that idea and implemented it with BSON so Crockford saying that doesn't mean it'll stop people from implementing variations on his original idea. Well, you can always base64 it as was said previously in this thread. Anyway, if you're handling large blobs often enough that you'd need specialized support for it, JSON might not be the right choice.
|
|
#
?
May 30, 2012 00:57
|
|
|
I can take a token stream from Jackson and write an extremely simple state machine to populate a data structure of my choosing. The moment this is not the case is the moment that JSON stops being more useful than XML, IMO. People who think it's okay to just add some syntax to a text interchange format because it makes their lives simpler should be forced to work at lower levels and see that they're not eliminating complexity, they're just putting it elsewhere. Just base64-encode your binary blobs, if you're going to use JSON, or use a binary format. I support JSON schema because it's validation and not an extension of the syntax itself (as I understand it), but the kind of person who adds extensions to the syntax itself of a straightforward format "because it makes it nicer" are terrible, terrible people who have ignorantly wrought destruction on productivity in the name of good. No, I'm not at all traumatized by someone who (several years ago) claimed that XML parsers should allow spaces in tag names and went ahead and wrote a lovely, buggy XML parser to foist his "gift" on all of his underlings, why do you ask? (second paragraph edited for clarity) Doctor w-rw-rw- fucked around with this message at 02:25 on May 30, 2012 |
|
#
?
May 30, 2012 01:52
|
|
|
Zombywuf posted:Have we just invented a JSON ORM? You don't really need one, since in either Mongo or CouchDB you can just put json data right into them. Also, ^ my god...
|
|
#
?
May 30, 2012 02:22
|
|
|
trex eaterofcadrs posted:You don't really need one, since in either Mongo or CouchDB you can just put json data right into them. Which part? Again, I probably wouldn't use a JSON schema, but it's not as abhorrent as tacking on extensions that make it harder to parse.
|
|
#
?
May 30, 2012 02:24
|
|
|
Doctor w-rw-rw- posted:Which part? Again, I probably wouldn't use a JSON schema, but it's not as abhorrent as tacking on extensions that make it harder to parse. Xml tags w/ spaces. That's "quit on the spot" kind of poo poo right there.
|
|
#
?
May 30, 2012 02:27
|
|
|
I was just looking through the pictures I took of bad code at my last job, and I saw this and it made me chuckle:C# code:I forget if my spirit was too crushed to bother refactoring by that point, but this would've made a lot more sense: C# code:
|
|
#
?
May 30, 2012 04:27
|
|
|
xf86enodev posted:This is btw the main reason why JSON is the best data exchange format. I have to write these APIs and just like relying on the user to make security decisions is an automatic failure, relying on the programmer to read and fully comprehend the docs is doomed from the start. I have no desire to reinvent XML (or God forbid XSD) but some basic ability to describe my API in a standardized way would be extremely helpful. Depending on my library/platform, it could even be automatic and verified by the compiler to match the code (to some degree). Jonnty posted:Are you suggesting some sort of automated parsing system? Excellent idea, we could call it a "parser" and put it in the standard library of Literally Every Language. JavaScript's idea of what constitutes an object doesn't always mesh with other languages... And some platforms may or may not have JSON parsers. Everyone ends up reinventing the wheel over and over.
|
|
#
?
May 30, 2012 04:29
|
|
|
Ender.uNF posted:some platforms may or may not have JSON parsers. json.org lists parsers for ASP, ActionScript, Bash, BlitzMax, C, C++, C#, Clojure, Cobol, ColdFusion, D, Delphi, E, Erlang, Fantom, Go, Haskell, HaXe, Java, JavaScript, Lisp, LotusScript, Lua, Matlab, Objective-C, OCaml, OpenLaszlo, Perl, PHP, Pike, PL/SQL, PowerShell, Prolog, Puredata, Python, Qt, R, Racket, Rebol, RPG, Ruby, Scheme, Squeak, Symbian, Tcl, VisualBasic and Visual FoxPro, and most of those languages offer several implementations to pick from. It's pretty available.
|
|
#
?
May 30, 2012 04:34
|
|
|
Ithaqua posted:I was just looking through the pictures I took of bad code at my last job, and I saw this and it made me chuckle: I think the fact that the method is called SetNull is horrible. I would have no idea what s = SetNull(s) would mean in code. And it's not even static? e: this would be horrible even in a language without the null coalescing operator. I'd probably just write s = (s == null) ? "" : s;. There's absolutely no need for a function there at all. Look Around You fucked around with this message at 05:31 on May 30, 2012 |
|
#
?
May 30, 2012 05:27
|
|
|
Internet Janitor posted:json.org lists parsers for ASP, ActionScript, Bash, BlitzMax, C, C++, C#, Clojure, Cobol, ColdFusion, D, Delphi, E, Erlang, Fantom, Go, Haskell, HaXe, Java, JavaScript, Lisp, LotusScript, Lua, Matlab, Objective-C, OCaml, OpenLaszlo, Perl, PHP, Pike, PL/SQL, PowerShell, Prolog, Puredata, Python, Qt, R, Racket, Rebol, RPG, Ruby, Scheme, Squeak, Symbian, Tcl, VisualBasic and Visual FoxPro, and most of those languages offer several implementations to pick from. It's pretty available. Indeed. JSON is so simple that assuming you can quote stuff properly, your choice of tokens are pretty much "{", "}", "[", "]", ",", "false", "true", "null", field names (string + a colon) , numbers, and strings (see Jackson JsonToken javadoc). Any language capable of even basic string operations should parse no problem. ...unless you decide to add a bunch of bullshit to the language specification, like functions. Gah. EDIT: ^^^ Oh man, I wish Java had the null coalescing operator. I suppose my solution of using Optional<T> from Guava mixed with .or(defaultValue) is a close second.
|
|
#
?
May 30, 2012 05:30
|
|
|
Doctor w-rw-rw- posted:Indeed. JSON is so simple that assuming you can quote stuff properly, your choice of tokens are pretty much "{", "}", "[", "]", ",", "false", "true", "null", field names (string + a colon) , numbers, and strings (see Jackson JsonToken javadoc). Any language capable of even basic string operations should parse no problem. Optional looks pretty cool, but it's kind of funny how the comments on the API explanation act like it's a novel concept when it isn't at all. e: Java needs first class functions. Then it may get somewhat more usable. e2: apparently guava adds some support for functional programming too. Huh. I'd never actually heard of the library before (but then I avoid java as much as possible) Look Around You fucked around with this message at 05:49 on May 30, 2012 |
|
#
?
May 30, 2012 05:45
|
|
|
|
| # ? May 21, 2024 06:28 |
|
|
Look Around You posted:Optional looks pretty cool, but it's kind of funny how the comments on the API explanation act like it's a novel concept when it isn't at all. quote:Optional is not intended as a direct analogue of any existing "option" or "maybe" construct from other programming environments, though it may bear some similarities. Ahahaha.
|
|
#
?
May 30, 2012 05:49
|
|
