[review][json] My review

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [review][json] My review

Boost - Dev mailing list
On 23/09/2020 13:36, I wrote:

> On 23/09/2020 12:52, Vinnie Falco wrote:
>> The interfaces are built up in layers. At the lowest layer you have
>> basic_parser which concerns itself only with processing the input
>> buffer and turning it into semantic components. It does _not_ have the
>> responsibility of buffering input to present it as a larger component,
>> that's the job of the handler. basic_parser is exposed to users so
>> they can use their own schemes for dealing with the semantic
>> components.
>>
>> Above basic_parser, you have parser which uses value_stack. The
>> value_stack does take responsibility for buffering input, and
>> producing DOM values. As with basic_parser, both of these components
>> are exposed to users so they can write their own layers on top.
>
> My point is that this seems like the wrong choice of layers.  As it
> stands, consumers should never care about the basic_parser layer, and
> instead will actually want a different layer (not currently exposed)
> that is between the two, which exposes complete values that are not in
> any DOM.
>
> The current form of basic_parser could still exist, if you like, but it
> should be made an implementation detail and the complete-value
> basic_parser actually exposed to consumers.

To restate this in a clearer way: it is still my belief that aspects of
json::parser performance considerations have "polluted" the design of
json::basic_parser to the point where it is not actually a meaningful
interface.

As such I strongly recommend that json::basic_parser be turned into an
implementation detail and not part of the public-facing part of the
library.  The library should only be used via its DOM interface
(json::parser/json::value), as that is the only one that is actually
properly baked.

I don't regard this as a reason to change my vote to accept the library
(and it's too late anyway), as the DOM interface by itself is highly
useful.  I just think that the basic_parser interface should be treated
as out of scope.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review][json] My review

Boost - Dev mailing list
On Tue, Sep 29, 2020 at 6:27 PM Gavin Lambert via Boost
<[hidden email]> wrote:
> As such I strongly recommend that json::basic_parser be turned into an
> implementation detail and not part of the public-facing part of the
> library.

Does anyone else agree?

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review][json] My review

Boost - Dev mailing list
Vinnie Falco wrote:
> On Tue, Sep 29, 2020 at 6:27 PM Gavin Lambert via Boost
> <[hidden email]> wrote:
> > As such I strongly recommend that json::basic_parser be turned into an
> > implementation detail and not part of the public-facing part of the
> > library.
>
> Does anyone else agree?

I don't. If you don't like basic_parser, don't use it. It's not clear to me
what anyone would gain from preventing others from using it.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review][json] My review

Boost - Dev mailing list
On Wed, Sep 30, 2020 at 8:30 AM Peter Dimov <[hidden email]> wrote:
> I don't. If you don't like basic_parser, don't use it. It's not clear to me
> what anyone would gain from preventing others from using it.

If Boost.JSON is accepted and we are targeting December ship date, I
am weakly in favor of making basic_parser private for one release so
we can work out more details. We might need to tune the API to achieve
the space savings we want.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review][json] My review

Boost - Dev mailing list
śr., 30 wrz 2020 o 17:39 Vinnie Falco via Boost <[hidden email]>
napisał(a):

> On Wed, Sep 30, 2020 at 8:30 AM Peter Dimov <[hidden email]> wrote:
> > I don't. If you don't like basic_parser, don't use it. It's not clear to
> me
> > what anyone would gain from preventing others from using it.
>
> If Boost.JSON is accepted and we are targeting December ship date, I
> am weakly in favor of making basic_parser private for one release so
> we can work out more details. We might need to tune the API to achieve
> the space savings we want.
>

I support this decision. Good interfaces are an important part of boost, so
it may be better to wait with exposing it. Also, you can call it an
implementation detail but nonetheless put it in a header accessible by the
users. The eager ones can still use it, even if it is not part of the
official interface.

Regards,
&rzej;


> Thanks
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [review][json] My review

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, 30 Sep 2020 at 17:15, Vinnie Falco via Boost <[hidden email]>
wrote:

> On Tue, Sep 29, 2020 at 6:27 PM Gavin Lambert via Boost
>
> <[hidden email]> wrote:
>
> > As such I strongly recommend that json::basic_parser be turned into an
>
> > implementation detail and not part of the public-facing part of the
>
> > library.
>
>
>
> Does anyone else agree?


Emphatically not.

Without basic_parser it would not be possible to parse directly to struct
and avoid building a redundant DOM.


>
>
>
> Thanks
>
>
>
> _______________________________________________
>
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> --
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12