This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25986 - Signify JSON as a return value
Summary: Signify JSON as a return value
Status: RESOLVED WORKSFORME
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-05 07:41 UTC by Anne
Modified: 2014-06-05 14:10 UTC (History)
5 users (show)

See Also:


Attachments

Description Anne 2014-06-05 07:41:06 UTC
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().
Comment 1 Boris Zbarsky 2014-06-05 13:02:24 UTC
Will there be processing model differences of some sort from "object"?  If so, what will they be?
Comment 2 Anne 2014-06-05 13:08:18 UTC
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`.
Comment 3 Tab Atkins Jr. 2014-06-05 13:13:27 UTC
Agreed - having a typedef for "JSON" seems like it would make the signatures much easier to understand.
Comment 4 Boris Zbarsky 2014-06-05 13:14:06 UTC
If there's no particular processing model difference, why not just do "typedef object JSON"?
Comment 5 Anne 2014-06-05 13:31:47 UTC
Fair.
Comment 6 Robin Berjon 2014-06-05 14:10:18 UTC
(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.