41–50 of 103 posts
It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.
It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. HTML is what it is, nothing else is what HTML is, and HTML is going to be around a good long while.
Here's the part that I don't particularly like, speaking of subtle incompatibilities:
EXAMPLE 2: Multiple Values
// produces
{
"bottle-on-wall": [1, 2, 3]
}
I don't know of any common patterns for working with "a thing or a list of things" in JSON; that kind of type mixing is the thing you hope to get away from by defining a good API. But all code that handles HTML JSON is going to have to deal with these maybe-list-maybe-not values, in a repetitive and boilerplatey way.
I hope that a standard such as this will eventually be adopted by real-life frameworks such as Django REST Framework, but I also hope that they just reject the possibility of multiple fields with the same name.
Let me say first of all that I'm glad they're working on standardizing this. When making REST APIs, I find HTML form scaffolds incredibly useful, but it means that you probably have to accept both JSON (because JSON is reasonable) and occasional form-encoding (because forms), leading to subtle incompatibilities. Or you have to disregard HTML and turn your forms into JavaScript things that submit JSON. Either way, the…
Let me say first of all that I'm glad they're working on standardizing this. When making REST APIs, I find HTML form scaffolds incredibly useful, but it means that you probably have to accept both JSON (because JSON is reasonable) and occasional form-encoding (because forms), leading to subtle incompatibilities. Or you have to disregard HTML and turn your forms into JavaScript things that submit JSON. Either way, the…
PHP handles this by having lists like this by requiring you to use an I put name like "bottle-on-a-wall[]". The brackets indicate that it should be a list. I don't hate this convention...
{ "name": "Bender" , "hind": "Bitable" , "shiny": true } Who puts commas at the start of a continuing line? What good could that possibly do?
It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments. I've seen people do this in the SELECT portion of SQL queries too. Personally, I hate this.
UPDATE FOO
SET BAR = 1
, BAZ = 2
, QUUX = 3
WHERE ALICE = 1
AND BOB =2
AND CHARLIE = 3 "files": [{
"name": "dahut.txt",
"src": "data:text/plain;base64,REFBQUFBQUFIVVVVVVVVVVVVVCEhIQo="
}]
Earlier quoted context omitted.
It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments. I've seen people do this in the SELECT portion of SQL queries too. Personally, I hate this.
I do it in UPDATES UPDATE FOO SET BAR = 1 , BAZ = 2 , QUUX = 3 I like it that way. Makes it clear the relationship between the continuing lines and their parents. Just the natural extension of WHERE ALICE = 1 AND BOB =2 AND CHARLIE = 3
In your example, I don't know SET BAR = 1 isn't the end until I read the next line.
Earlier quoted context omitted.
I do it in UPDATES UPDATE FOO SET BAR = 1 , BAZ = 2 , QUUX = 3 I like it that way. Makes it clear the relationship between the continuing lines and their parents. Just the natural extension of WHERE ALICE = 1 AND BOB =2 AND CHARLIE = 3
That seems backwards to me. I put the operator on the previous line so I know the expression has more parts coming. In your example, I don't know SET BAR = 1 isn't the end until I read the next line.
I mean, it's kind of the SQL analogue to the
MyObject
.Child
.Grandchild
.ItsMethod(stuff)
.HeyThatReturnedAnotherObject()
.MoreObject(moreStuff)