From: VinÃcius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2021-02-24 12:55:40
Em ter., 23 de fev. de 2021 Ã s 15:56, Peter Dimov via Boost
> Other JSON (and serialization) libraries already offer a similar mechanism,
> e.g. https://github.com/nlohmann/json#arbitrary-types-conversions. But since
> each library has its own private way to annotate types, a programmer needs
> to repeat the type annotations for every library he wants his type to be
> known to. This is unnecessary and undesirable, and a standard mechanism to
> describe types avoids it.
I agree with the diagnosis, but I'm not so keen on the solution. I
insist you broaden your view and take a look at other libraries that
need manual annotation. If your solution only covers the JSON case, it
could very well be just an abstraction inside the JSON library and
isn't a vocabulary at all.
The documentation lacks a section comparing your solution with what's
available on the market today. I'll give you a starter pack on what's
to look for, but you shouldn't limit yourself to these links:
Except for EFL which is an unfortunately ignored project, all
libraries listed are widely used. All of them have been in the market
for quite some time and are battle-tested.
Do notice that each project pursues manual annotation for different
reasons and none of them are JSON related. In one project, the
property system is the core of an animation system. In such a place,
it's not enough to have fragmented symbols that have no connection
with one another at all. You need to glue properties to the real
getters and setters and that's what must be used as changing one
property must trigger signals to other parts of the system. In fact,
if you don't provide at least this, it's hard for me to see which
value I'd get from Describe that I can't already get from PFR or
In the other two systems linked, properties are used to extract the
"OO/class layout" and export them for use in language bindings without
the need for a C/C++ parser in the other languages. JSON serialization
is just a small part of the problem that this library tries to tackle.
The research might be daunting, but it always pays off. Research is
what separates a "cool hack" from "serious solutions". I'm actually
looking forward to using this library myself.
Furthermore, I won't have time to participate in Describe review. So I
thought I could share this info with you now and trust you'll just do
the right thing here. Have fun.
-- VinÃcius dos Santos Oliveira https://vinipsmaker.github.io/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk