- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 9 Jul 2014 09:18:57 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Robin Berjon <robin@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Jul 9, 2014 at 9:14 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/9/14, 11:51 AM, Robin Berjon wrote:
>>
>> And if we could kill serializer with the same stone, all the better.
>
>
> Serializer is a tad different.
>
> The issue with stringifier is that it doesn't actually describe the
> behavior. It just specifies that a toString method is created, but what
> that toString method does has to be described in prose. So there is no
> significant win over just having "toString" in the IDL with prose describing
> the behavior, except in terms of language-independence.
>
> For serializer, it can provide behavior, not just a function name. So
> replacing it would involve a lot more prose.
>
> On the other hand, I think serializer as currently specified is somewhat
> over-engineered. In practice, Gecko implements only the "serializer = {
> attribute };" form (and we give it a different name, "jsonifier", in our IDL
> to make it clear that it's not the thing that's in the spec). This is the
> form that most closely corresponds to what people may want when they
> JSON.stringify an object in practice. Are there actual use cases for the
> other forms that warrant having them in IDL?
And note that just defining a toJSON() method on the object already
lets you hook JSON.stringify(), so if JSON is the only thing we're
using it for, we don't need a special form for that either.
~TJ
Received on Wednesday, 9 July 2014 16:19:45 UTC