Closed m-mcgowan closed 1 month ago
Hi @m-mcgowan ,
yeah, I agree, this makes a lot of sense and it is also very easy to do.
All you have to do is to split up the has_reflector
concept in here into two separate ones (if you could also put them in a separate file internal/has_reflector.hpp
, that would be great):
https://github.com/getml/reflect-cpp/blob/main/include/rfl/internal/has_reflection_method_v.hpp
Then you have to insert them in the appropriate places in here.
https://github.com/getml/reflect-cpp/blob/main/include/rfl/parsing/Parser_default.hpp
That's it. A PR is welcome, otherwise I can just do it myself.
And when you do this, if you could also adapt the documentation that would be great:
https://github.com/getml/reflect-cpp/blob/main/docs/custom_parser.md
Thanks for the pointers, I'll give it a shot.
Resolved.
Hi there!
I've been using reflect-cpp for a few weeks, and it's really helping me avoid boilerplate code. I have an application model, which I'm using reflection to implement a simple CLI where the model can be viewed container hierarchy (with names and types) and values can be retrieved or set. (The CLI works on the desktop and also targeted to embedded devices.)
The recent addition of Reflector support makes customizing serialization/deserialization even easier. However, I have a case where not all types are writable, and it makes no sense to write to them. For example, I have a queue of events, which can be inspected, but not set. (And the queue is not const because parts of the app need to write to the queue.)
One possible way of implementing this is to separate the Reflector into two distinct capabilities - one for reading one for writing. At present, the reflector concept covers both inseparably.
I'd be happy to help submit a PR if these ideas seem like a good way to go.