On Fri, Mar 16, 2018, 4:58 PM Anders Rundgren <[email protected]> wrote:
> On 2018-03-16 21:41, Mike Samuel wrote: > > > > > > On Fri, Mar 16, 2018 at 4:34 PM, C. Scott Ananian <[email protected] > <mailto:[email protected]>> wrote: > > > > On Fri, Mar 16, 2018 at 4:07 PM, Anders Rundgren < > [email protected] <mailto:[email protected]>> > wrote: > > > > > To restate my main objections: > > > > I think any proposal to offer an alternative stringify instead of a > string->string transform is not very good > > and could be easily improved by rephrasing it as a string->string > transform. > > Could you give a concrete example on that? > > > I've given three. As written, the proposal produces invalid or low quality output given (undefined, objects with toJSON methods, and symbols as either keys or values). These would not be problems for a real canonicalizer since none are present in a string of JSON. In addition, two distant users of the canonicalizer who wish to check hashes need to agree on the ancillary arguments like the replacer if canonicalize takes the same arguments and actually uses them. They also need to agree on implementation details of toJSON methods which is a backward compatibility hazard. If you did solve the toJSON problem by incorporating calls to that method you've now complicated cross-platform behavior. If you phrase in terms of string->string it is much easier to disentangle the definition of canonicalizers JSON from JS and make it language agnostic. Finally, your proposal is not the VHS of canonicalizers. That would be x=>JSON.stringify(JSON.parse(x)) since it's deployed and used.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
