25986 2014-06-05 07:41:06 +0000 Signify JSON as a return value 2014-06-05 14:10:18 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED WORKSFORME P2 normal --- 1 annevk cam bzbarsky jackalmage mike public-script-coord robin public-webapps-bugzilla oldest_to_newest 107321 0 annevk 2014-06-05 07:41:06 +0000 Since IDL also helps (and I realize that it does not do this for everyone and that can improve upon it) with making object behavior more clear, it would be nice if there was a way to identify JSON other than using object or any. Both XMLHttpRequest and fetch() will be able to return JSON objects. XMLHttpRequest uses any for response. fetch() will have to do the same for its Promise<> returned from bodyAs(). 107345 1 bzbarsky 2014-06-05 13:02:24 +0000 Will there be processing model differences of some sort from "object"? If so, what will they be? 107346 2 annevk 2014-06-05 13:08:18 +0000 I don't think so. I thought it would be nice to indicate that something returns either JSON, a Blob, or a string. `(Blob or JSON or DOMString)` seems more clear than `any`. 107347 3 jackalmage 2014-06-05 13:13:27 +0000 Agreed - having a typedef for "JSON" seems like it would make the signatures much easier to understand. 107348 4 bzbarsky 2014-06-05 13:14:06 +0000 If there's no particular processing model difference, why not just do "typedef object JSON"? 107350 5 annevk 2014-06-05 13:31:47 +0000 Fair. 107358 6 robin 2014-06-05 14:10:18 +0000 (In reply to Tab Atkins Jr. from comment #3) > Agreed - having a typedef for "JSON" seems like it would make the signatures > much easier to understand. It wouldn't hurt if specs that manipulate JSON in memory (i.e. not as serialised JSON) had some common terminology in order to do so. Right now it's a bit all over the place.