users@jsonb-spec.java.net

[jsonb-spec users] [jsr367-experts] Re: Re: [2-DefaultMapping] Proposal

From: Romain Manni-Bucau <rmannibucau_at_tomitribe.com>
Date: Mon, 16 Mar 2015 19:05:13 +0100

Well on that topic I'd stay aligned with jsonp.

Plus each time I saw such an API it was never used or badly used - json to
xml formatter comes immediately to my mind.
Le 16 mars 2015 18:51, "Inderjeet Singh" <inder_at_alumni.stanford.edu> a
écrit :

>
>
> On Mon, Mar 16, 2015 at 9:50 AM, Romain MB <rmannibucau_at_tomitribe.com>
> wrote:
>
>> 2015-03-16 17:35 GMT+01:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
>> >
>> >
>> > 2015-03-16 17:21 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
>> >>
>> >> In Gson, we have a GsonBuilder.setPrettyPrinting() setting. This mostly
>> >> works but is inflexible.
>> >> However, I think a better approach is to allow a formatter object that
>> >> allows configuration per any formatting styles. You can use the
>> formatting
>> >> styles of an IDE such as Eclipse.
>> >
>> >
>> > But do you think that in practice people do need such customization? I
>> think
>> > they only need pretty printing for debuging purposes, where a readable
>> std
>> > format is fine.
>> >
>>
>> +1, this is a shortcut for a common use case IMO, but doesnt prevent
>> vendor to use properties to do much more
>
>
> If you are trying to create publishable documentation, customized printing
> is nice.
> It is not a strong requirement, and that is why we didn't implement it in
> Gson yet.
>
> BTW, my proposal () is equally developer-friendly since the developer will
> be doing something like this:
>
> builder.setPrintFormat(PrintFormats.PRETTY)
>
> But this allows them to pass their own formatter object.
>
> Inder
>