You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current approach to handling JSON feels somewhat suboptimal. Working with the id -> json map feels like an extra step, which, in my opinion, isn't entirely necessary. If the JSON serialization methods were made "pure", they could operate directly on a JSON string, which has the advantages of not modifying state and being more intuitive.
This method offers more clarity in the way we work with JSON. Also, by the convention used by forge-std, in this case the functions could be declared as pure. Of course this would break a lot of things... an alternative would be to add these as new methods (not ideal as the vm interface is already pretty big).
Thoughts?
Additional context
No response
The text was updated successfully, but these errors were encountered:
@odyslam any insight into why we went with the current approach? I feel like I recall expecting it to work in the way suggested here, and can't remember the rationale for the current approach.
Given scope of the change, if we do implement this, my suggestion would be to namespace the cheats behind a _v2 or something and if everyone agrees this is better then at some point there can be a breaking change to remove the old version
Component
Forge
Describe the feature you would like
Hi everyone!
The current approach to handling JSON feels somewhat suboptimal. Working with the id -> json map feels like an extra step, which, in my opinion, isn't entirely necessary. If the JSON serialization methods were made "pure", they could operate directly on a JSON string, which has the advantages of not modifying state and being more intuitive.
Consider the current method:
With a direct JSON string approach, it could be simplified to:
This method offers more clarity in the way we work with JSON. Also, by the convention used by
forge-std
, in this case the functions could be declared aspure
. Of course this would break a lot of things... an alternative would be to add these as new methods (not ideal as the vm interface is already pretty big).Thoughts?
Additional context
No response
The text was updated successfully, but these errors were encountered: