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
Currently, the toArray() function is defined in the Storable array. It's also currently the only way to properly export an object (e.g. using json_encode()). I might want to move it to another module, though, as it's not actually related to storing the objects and it makes sense to use it without a Good Manners storage.
Now, as of writing this I haven't done this yet, but I plan to make toArray() aware of unresolved properties (#131). However, unresolved properties are Manners-only functionality, meaning that we're introducing a dependency that I would rather live without.
I have come up with a solution, though. So, while it may take a long time before I get around to doing this, I want to record my solution nonetheless. The idea is to have an api of some sort that can be used to define what properties are exportable and what their values should be. The simplest solution would be to make the current toArray functionality a core part of the generated object and state that anything wanting to export the properties. The modifiers could then specify a post processing function that gets to postprocess the entire array. This properly allows for deletions and transformations flawlessly even when no ordering is guaranteed between the different modifiers.
On the other hand, it doesn't work as well for adding properties. If Modifier X wants to add property A and Modifier Y wants to transform it, the result depends on the order the modifiers get their say in. An alternative that doesn't have this problem is a more intricate system that still has multiple functions they can pass through, but has different hooks for adding fields, for deleting them and for transforming them.
The text was updated successfully, but these errors were encountered:
Currently, the
toArray()
function is defined in theStorable
array. It's also currently the only way to properly export an object (e.g. usingjson_encode()
). I might want to move it to another module, though, as it's not actually related to storing the objects and it makes sense to use it without a Good Manners storage.Now, as of writing this I haven't done this yet, but I plan to make
toArray()
aware of unresolved properties (#131). However, unresolved properties are Manners-only functionality, meaning that we're introducing a dependency that I would rather live without.I have come up with a solution, though. So, while it may take a long time before I get around to doing this, I want to record my solution nonetheless. The idea is to have an api of some sort that can be used to define what properties are exportable and what their values should be. The simplest solution would be to make the current
toArray
functionality a core part of the generated object and state that anything wanting to export the properties. The modifiers could then specify a post processing function that gets to postprocess the entire array. This properly allows for deletions and transformations flawlessly even when no ordering is guaranteed between the different modifiers.On the other hand, it doesn't work as well for adding properties. If Modifier X wants to add property A and Modifier Y wants to transform it, the result depends on the order the modifiers get their say in. An alternative that doesn't have this problem is a more intricate system that still has multiple functions they can pass through, but has different hooks for adding fields, for deleting them and for transforming them.
The text was updated successfully, but these errors were encountered: