Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding js member listeners #50

Open
sheepy9 opened this issue Sep 28, 2023 · 3 comments
Open

Adding js member listeners #50

sheepy9 opened this issue Sep 28, 2023 · 3 comments

Comments

@sheepy9
Copy link
Contributor

sheepy9 commented Sep 28, 2023

Hi, I really like your library. I think it provides a really elegant interface for serializing and deserializing json.

I would like to propose adding a feature that I think could be useful to the users of json_struct. The feature I would like to propose is having the ability to register listeners to struct members that will be called during deserialization.
For example, deserializing a Person object with the fields name and age could trigger methods registered as property listeners like onNameChanged(std::string) and onAgeChanged(int).
The syntax for adding these property listeners could be something similar to the existing workflow. Something along the lines of:

struct Person
{
    std::string name;
    unsigned age;
    void onNameChanged(std::string);
    void onAgeChanged(unsigned);

    JS_OBJECT(JS_MEMBER_WITH_LISTENER(name, &Person::onNameChanged), 
              JS_MEMBER_WITH_LISTENER(age, &Person::onAgeChanged));
};

The outcome of this would be that upon deserializing, the registered listeners would be triggered, which could enable some additional custom logic to run for every deserialized field.

I understand this feature might not exactly be part of the original scope for json_struct, but I think it might add real value to the library and increase its utility by adding something more than serializing and deserializing.

I would like to volunteer to write the implementation of this. Even if you think this feature doesn't belong in json_struct, I would still appreciate some pointers on how you would recommend integrating this in json_stuct, as I would like to give it a whirl anyway.

@jorgen
Copy link
Owner

jorgen commented Sep 29, 2023

Cool, I didnt see this until now. I will have a look to see how easy it is to implement. I'm thinking it would be cool to do it with a old and new value

@jorgen
Copy link
Owner

jorgen commented Sep 30, 2023

I have been thinking about this a bit. I might have disregarded this request earlier, but if we want this to be possible, maybe we should make a JS_PROPERTY macro instead. A property would then have a getter and setter. We would have to change the internals of the MI struct so that it could have either a member pointer or a couple of function pointers. We would then have to have a template function that either sets the member pointer or sets/gets the function dependent on "what type of MI" we have.

This would allow the user to "intercept" the get and set, getting the correct semantics for the listener and it would please the object oriented crowd 😄

@sheepy9
Copy link
Contributor Author

sheepy9 commented Oct 9, 2023

Hi, thanks for the input. I like the JS_PROPERTY macro idea. So if I understand correctly, internally, instead of accessing the member directly, json_struct would use the getter and setter. And this would also imply that the property doesn't even have to be a member of that C++ struct.

For example, I could register a property with just the getter and setter, while the actual member variable doesn't exist in the C++ struct. Json_struct would just use the getter for serialization and the setter for deserialization, and the user would implement the getters and setters in any way they see fit, whether that means simply getting and setting a member variable, or something more complex like fetching from some resource (file, DB etc) with the getter upon serialization, or written to the resource with the setter upon deserialization.

I have been a little busy the past week, and also this week, but I'm still interested in this in doing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants