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

Exportable properties API #132

Open
JasperHorn opened this issue Feb 12, 2020 · 1 comment
Open

Exportable properties API #132

JasperHorn opened this issue Feb 12, 2020 · 1 comment

Comments

@JasperHorn
Copy link
Collaborator

JasperHorn commented Feb 12, 2020

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.

@JasperHorn
Copy link
Collaborator Author

I think I have more or less done this in #131 if a bit differently. I'm not completely sure, though, so I'm keeping this one open for now.

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

1 participant