Define URL's toJSON() #229
Conversation
This makes it a little easier to use with JSON.stringify(). Fixes #137.
| @@ -2483,6 +2483,8 @@ interface URL { | |||
| attribute USVString search; | |||
| [SameObject] readonly attribute URLSearchParams searchParams; | |||
| attribute USVString hash; | |||
|
|
|||
| USVString toJSON(); | |||
There was a problem hiding this comment.
Even though I'm not a fan of the complicated serializer syntax, I do like the conciseness of just writing
serializer;which is more parallel to the existing iterable<USVString, USVString>; for URLSearchParams.
There was a problem hiding this comment.
Is the question one of having serializer; basically be a thing that produces a then-custom-defined toJSON, kinda like stringifier;?
The problem is that unlike stringifier;, where the return value is clear, the return value of toJSON could be all sorts of things. We could define serializer; to induce the equivalent of any toJSON(); but that's more annoying to work with than being able to usefully declare your return type...
There was a problem hiding this comment.
Indeed, I haven't thought of that. How about serializer<USVString>;? It also has the advantage of being more language-independent, while there are precedents for <> meaning "produces" with iterable.
There was a problem hiding this comment.
Why? We should be moving away from this baroque, hard-to-understand, "language independent" syntax in favor of simple, do-what-it-says JavaScript-derived syntax.
The only reason iterable is special is because it's a macro that expands to ~4 JS methods. For a simple stand-in for a JS method, we should not create an extra layer of abstraction that requires looking up the Web IDL spec to understand what it does.
There was a problem hiding this comment.
I'm going to assume @TimothyGu is okay with the PR as-is given five days have passed. Hope that's okay. (Still I'll wait a little longer with landing since the test required a further change.)
There was a problem hiding this comment.
@annevk, sorry about forgetting to reply. I'm okay with the PR in general. The bit about IDL notation is minor and does not affect the semantics anyway.
| @@ -2483,6 +2483,8 @@ interface URL { | |||
| attribute USVString search; | |||
| [SameObject] readonly attribute URLSearchParams searchParams; | |||
| attribute USVString hash; | |||
|
|
|||
| USVString toJSON(); | |||
There was a problem hiding this comment.
If “URL” interface will be implemented on PHP, should this method be implemented by the name of “jsonSerialize()” instead of “toJSON()”?
https://secure.php.net/manual/class.jsonserializable.php
There was a problem hiding this comment.
If you're porting the JavaScript URL class to PHP, you can do whatever you like, as there's no spec for that. It's up to you what you think is most intuitive for your developers (e.g. probably PHP has different naming conventions than JavaScript in many areas, not just JSON serialization).
There was a problem hiding this comment.
I get it. Thank you for your advice.
|
Tests: web-platform-tests/wpt#4702. |
PR-URL: #11236 Ref: whatwg/url#229 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
PR-URL: nodejs#11236 Ref: whatwg/url#229 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
PR-URL: #11236 Ref: whatwg/url#229 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
This makes it a little easier to use with JSON.stringify().
Fixes #137.