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

Add support for object without JsonSerializable #505

Conversation

DeveloperMarius
Copy link
Contributor

Hello,

I think it would be great when we add support for returning an object without the JsonSerializable.
The function get_object_vars() only returns the public variables of an object (when it is used out of the class itself). But when we create an ReflectionClass and then get the Properties, check if they are non static and add them, this would be a great alternative.
The only thing I'm not sure about is wheather to add private, protected and public variables to the return or to just return the private or the public.

~ Marius

@skipperbent
Copy link
Owner

Can't figure out if I like this. I can understand the reasoning behind it, but I'm not sure if it's something that the router should be handling (assuming what methods/data etc to return) like some kind of voodoo. Using the ReflectionClass is bad practice in my opinion as it's slow and the \JsonSerializable interface is made for exactly this.

However if this feature is really something that is needed, I think it would make more sense to create a JsonSerializable abstract class that implements the \JsonSerializable interface and then add all the parsing to that class, maybe some options to set which methods/variables to serialize etc. That way the parsing can be easily overwritten/customized if needed and the Response class will remain clean.

@DeveloperMarius
Copy link
Contributor Author

Okay, no problem. Was just an idea :)

@DeveloperMarius DeveloperMarius deleted the json-response branch November 15, 2022 09:20
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

Successfully merging this pull request may close these issues.

None yet

2 participants