W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: [webidl] Stringifiers should allow optional arguments

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 9 Jul 2014 09:18:57 -0700
Message-ID: <CAAWBYDD_khjm_6esjyEfp8jv2VfbjiAY34g829qSXLaDKGrwCA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC