3 ms·

Is your idea of having # as a date prefix and suffix compatible with having json be a subset of valid javascript? Because that was one of its original selling p

Is your idea of having # as a date prefix and suffix compatible with having json be a subset of valid javascript? Because that was one of its original selling points. Are you thinking something like { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } Or were you thinking { "business": "Jim's Hat Shop", "date_visited": "#2016-05-03#" }

PretzelFisch 10y ago
I was thinking { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } because the parsing would be simple while the other would work.
- pfooti 10y ago
  Personally, this isn't bad - some kind of literal notation for date objects seems like a good idea (we already have octal and binary literals). The other option ("#date#") is bad, IMO, since it's a magic string. I don't like magic strings because they blow up at unexpected times. Imagine the notice to the users: "please stop using the hashtag #racecar#, we know palindromes are cool, but it is causing our database to crash". I had similar issues with CDATA blocks in XML, actually - escaping strings to afford reasonable parsing is never fun.
  - sopooneo 10y ago
    Your note about octal and binary literals sort of goes back and forth compared to the idea of date literals for me. Because octal and binary literals are supported in vanilla javascript, but are not explicitly supported in JSON. However, throwing them in seems like only a minor transgression since they are native to javascript, and are effectively just another representation of a number. On the other hand, the date literal you suggest is not part of javascript. And on that note, why not just use timestamps for dates in json?
- sopooneo 10y ago
  But isn't it a huge change to make json not be valid javascript? These days no one in good conscience just uses "eval()" in a js app, so maybe it doesn't matter anymore, but still, it seems like that is suggesting a massive departure.

PretzelFisch 10y ago

I was thinking { "business": "Jim's Hat Shop", "date_visited": #2016-05-03# } because the parsing would be simple while the other would work.

pfooti 10y ago
Personally, this isn't bad - some kind of literal notation for date objects seems like a good idea (we already have octal and binary literals). The other option ("#date#") is bad, IMO, since it's a magic string. I don't like magic strings because they blow up at unexpected times. Imagine the notice to the users: "please stop using the hashtag #racecar#, we know palindromes are cool, but it is causing our database to crash". I had similar issues with CDATA blocks in XML, actually - escaping strings to afford reasonable parsing is never fun.
- sopooneo 10y ago
  Your note about octal and binary literals sort of goes back and forth compared to the idea of date literals for me. Because octal and binary literals are supported in vanilla javascript, but are not explicitly supported in JSON. However, throwing them in seems like only a minor transgression since they are native to javascript, and are effectively just another representation of a number. On the other hand, the date literal you suggest is not part of javascript. And on that note, why not just use timestamps for dates in json?
sopooneo 10y ago
But isn't it a huge change to make json not be valid javascript? These days no one in good conscience just uses "eval()" in a js app, so maybe it doesn't matter anymore, but still, it seems like that is suggesting a massive departure.