tag:blogger.com,1999:blog-34454975.post7772067229862049279..comments2023-06-28T16:58:41.189+02:00Comments on Web Reflection: Why JSON Won ... And Is Good As It IsAndrea Giammarchihttp://www.blogger.com/profile/16277820774810688474noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-34454975.post-54797666785027756262012-08-30T17:43:01.450+02:002012-08-30T17:43:01.450+02:00if not that visible, there was a link:
https://dev...if not that visible, there was a link:<br />https://developer.mozilla.org/en-US/docs/DOM/The_structured_clone_algorithmAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-89152928412325832142012-08-30T17:42:23.052+02:002012-08-30T17:42:23.052+02:00if you could communicate binary content in advance...if you could communicate binary content in advance, JSON is compatible ... this is what I was saying. The problem is that through current web technologies it does not scale as binary capable protocol but <a rel="nofollow">it could do it already and without problems</a>.Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-12110328935204436572012-08-30T17:01:11.479+02:002012-08-30T17:01:11.479+02:00I dont agree ;) since http supports binary transfe...I dont agree ;) since http supports binary transfers yet JSON doesn't since the attribute values (with binary data) would corrupt the json payload. And query strings are just sort of pointers to data, like a filename. I don't follow you on why the payload has anything to do with the format of the query strings. JSON is part of the http payload and not the urls, right? ;) Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-18492016972740820432012-08-30T11:20:52.676+02:002012-08-30T11:20:52.676+02:00it is data agnostic, the fact you need base64 is b...it is data agnostic, the fact you need base64 is because http urls expect that, not because JSON is missing something. You know what I mean?<br /><br />It's like saying that http is not a protocol because it does not support binary on query strings, cookies, etc etc ... don't you think?Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-90992367598983602732012-08-30T10:31:34.488+02:002012-08-30T10:31:34.488+02:00...JSON dont support binary data. Having to Base64......JSON dont support binary data. Having to Base64 encode/decode data or use alternative pathways sucks. A 'real protocol' should be data agnostic. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-84353968174736705072012-08-21T15:14:10.016+02:002012-08-21T15:14:10.016+02:00as transport data protocol? as data schema to tran...as transport data protocol? as data schema to transport data? as "it could be json:{valid_json}" ? Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-42686096063618164492012-08-21T13:28:05.527+02:002012-08-21T13:28:05.527+02:00I don't mean to sound facetious, but I am inte...I don't mean to sound facetious, but I am interested to know why you refer to JSON as a protocol? <br /><br />I realize that you could make it fit the definition of 'protocol' but I wonder what value that adds?<br /><br />And given you say JSON is a protocol, therefore this and that, I suppose it is important to understand why you use that term.<br /><br />Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-75945228377955773672012-08-20T00:50:29.433+02:002012-08-20T00:50:29.433+02:00for performance? sure that would be but again, it&...for performance? sure that would be but again, it's a protocol, not a "forget you are a developer, bring it on, I'll decide what's good or not for you" method ... throwing errors natively on recursion rather than implementing your own recursion checker ... that's cool for me already :DAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-50573684851545537902012-08-20T00:37:36.293+02:002012-08-20T00:37:36.293+02:00actually, I wonder if my next post should be Objet...actually, I wonder if my next post should be Objet.freeze(Object.prototype) as mandatory very first script you write in any web pageAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-37635348973354273762012-08-20T00:37:26.999+02:002012-08-20T00:37:26.999+02:00> Iwould agree with your code if I could chose ...> Iwould agree with your code if I could chose if I need it...<br /><br />I started that whole run-in with Crockford because I specifically wanted to add the "drop recursion" behavior natively to `JSON.stringify()`, and I said it should probably be opt-in with a flag. So I agree with that perspective. But it's clear what Crockford thinks about that.<br /><br />So, is it a lesser evil to have to use your own non-standard serializer instead of the built-in `JSON.stringify()`, or to monkey-patch objects so that the built-in standard parser behaves as desired?<br /><br />Tough call, but I think the latter is <b>slightly</b> better.Kyle Simpsonhttp://getify.menoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-81286609623805522942012-08-20T00:34:47.415+02:002012-08-20T00:34:47.415+02:00also, as you already introduced defineProperty ove...also, as you already introduced defineProperty over an Object.prototype, think how many would feel OK introducing not enumerable, writable, and configurable, Object.prototype.whatever so that everyone else is screwed if that method does not provide what is expected or is too obtrusive as toJSON could be, since toJSON is as obtrusive as toString, and valueOf ... DO NOT TOUCH IT, thanks!Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-17515025988750471502012-08-20T00:32:16.671+02:002012-08-20T00:32:16.671+02:00the defineProperty hint is something I don't w...the defineProperty hint is something I don't want to deal with, eventually something your proposal should do by default but again, I might not want your proposal to work with my generic objects that I did not, on purpose, decide to make safe ... all I am saying, toJSON is indeed a very special case I am sorry i don't want to give you the ownership (you as your code) to deal with my objects ... maybe I want recursion to be there 'cause I don't want that object to be used with any transport protocol? Maybe I want a different behavior? Iwould agree with your code if I could chose if I need it ... if it's a must have 'cause I don't care about recursion ... then I don't want it, 'cause I do care and maybe that recursion was a mistake, a bug, a problem, I want to deal it, and not want to solve it magically 'cause someone introduced that Object.prototype.toJSON method.<br /><br />Leave objects as they are, reuse that method whenever you want ... you need 1 callback, and the ability to attach it to any object that would like to do not care about recursion during serialization.<br /><br />All objects ... oh well, that's a bit too much, some dev knows what he's doing ;-)Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-88945354743578320472012-08-20T00:26:25.049+02:002012-08-20T00:26:25.049+02:00I similarly don't agree with, in general, exte...I similarly don't agree with, in general, extending the Object prototype (or any other native). I've spoken out against it too many times to count.<br /><br />But I think `toJSON()` is a very special case, and as such that general position does not necessarily apply. Blindly applying any "rule" (no matter how well intended that rule is) without thinking about the specific circumstances is, IMHO, short-sighted.<br /><br />You're so concerned about having to write that guard into all your for-in loops? Easily fixed:<br /><br />Object.defineProperty(Object.prototype,"toJSON",{enumerable:false});<br /><br />I just don't see it being such a big deal in this one specific special use-case. `toJSON()` <b>only</b> exists for the purpose of JSON serialization (by `JSON.stringify()`).<br /><br />It's not at all the same thing as suggesting to add methods to `String` or whatever.Kyle Simpsonhttp://getify.menoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-36243241335170907692012-08-19T23:18:51.957+02:002012-08-19T23:18:51.957+02:00I forgot ... I don't personally use JSLint nei...I forgot ... I don't personally use JSLint neither ... and NO, I don't personally want to write hasOwnProperty per each loop ... I discourage everyone to use any library that pollutes Object.prototype ... even if some example, for posting purpose, could have been showed here.Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-18878962371981824242012-08-19T23:17:23.650+02:002012-08-19T23:17:23.650+02:00the hasOwnProperty() forced check for each bloody ...the hasOwnProperty() forced check for each bloody fo/in loop is the reason I don't like libraries that pollute Object.prototype and never used them ... hasOwnProperty per each check and per each object in an application slows down everything 100X and I write mainly for mobile ... i don't want this crap within my code, if I have Object.prototype.something anywhere, I drop that code 'cause it cannot be good no matter what it does, imhoAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-55401005848746211312012-08-19T23:05:42.653+02:002012-08-19T23:05:42.653+02:00It's easily avoided by running your for-loops ...It's easily avoided by running your for-loops with the, ironically insisted on by crockford-jslint, `hasOwnProperty()` guard, as I do, always, if you do a for-in style loop.<br /><br />for (var i in obj) { if (obj.hasOwnProperty(i)) {<br /><br /> // do stuff<br /><br />}}<br /><br />I think any responsible developer, especially one who writes code that may be used in other environments besides their own, is already aware of this issue and this simple fix. They're especially aware of it if they use a linter which warns about it.<br /><br />> If I know it ... I know how to avoid them, adding some extra logic that does not need such generic solution for everyone else.<br /><br />I explained my two use cases for having a generic `toJSON` to use in conjunction with `JSON.stringify()`, <a href="https://gist.github.com/3373779#gistcomment-400333" rel="nofollow">in this comment</a>.Kyle Simpsonhttp://getify.menoreply@blogger.comtag:blogger.com,1999:blog-34454975.post-47173730288744995892012-08-19T22:49:34.210+02:002012-08-19T22:49:34.210+02:00There's no magic behind serialization .. I mea...There's no magic behind serialization .. I meant, behind serialization over recursionAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-67144502186088860822012-08-19T22:48:44.880+02:002012-08-19T22:48:44.880+02:00Kyle ... 6th June 2005 ... and I still agree.
The...Kyle ... <a href="http://erik.eae.net/archives/2005/06/06/22.13.54/" rel="nofollow">6th June 2005</a> ... and I still agree.<br /><br />There's no magic behind serialization ... we, as developers, must understand it and avoid it when it comes to data transports ... then we can recreate it and use it to create any sort of memory leak in our code without caring ... but no, I don't like anyone creating any sort of Object.prototype.toJSON method ... EVER! I know what I am doing and I would never implement such solution for my lack of logic, architecture, or time 'cause I could not use my own toJSON() for my own objects if it's a bout removing circular references ... <br /><br />Last, but not least, if I don't know I have circular references in my code, I am doing it wrong, whatever it is.<br />If I know it ... I know how to avoid them, adding some extra logic that does not need such generic solution for everyone else.<br /><br />Sorry but this is my take on any Object.prototype thingyAndrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-75695380458785290962012-08-19T22:18:05.745+02:002012-08-19T22:18:05.745+02:00FWIW, this is why I was trying to suggest to Crock...FWIW, this is why I was trying to suggest to Crockford that JSON.stringify() should ignore circular references (just like it ignores functions) if it encounters them while serializing an object.<br /><br /><a href="https://github.com/douglascrockford/JSON-js/issues/39" rel="nofollow">JSON-js issue #39</a><br /><br />I have written a generic Object.prototype.toJSON() which does exactly this task: prefilter an object to remove/ignore any object references which create circular references.<br /><br /><a href="https://gist.github.com/3373779" rel="nofollow">Object.prototype.toJSON()</a>Kyle Simpsonhttp://getify.menoreply@blogger.com