-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Serializer][RFC] Context object as an alternative to array builders #45330
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
Comments
@dunglas, may I attract your attention to this RFC? |
I would very much prefer to not change the interfaces again. Using But what about allowing builders directly into the $context variable, indexed by numbers?
@mtarld WDYT? Anyone up to digging into this idea? |
Yes I already have worked on a PR like that. But it simplify a lot normalizers and encoders because they is no need to validate the context in them Maybe I can retry with your help if you want? |
Why?
We can instead index them by class name, so that it's easy to get a context instance or check that it's not set.
You don't need that if the config objects are immutable (then they are not builders, of course). Simply replace certain config with a new one if you want to change it. |
Because the gain doesn't look worth the cost to me. An object there looks barely better than an array to me. That's just my current understanding of the topic of course. |
Replacing context could not work everywhere IMHO. As an example, the protected For the record, here was the implementation I tried weeks ago: mtarld@e165bbe. |
@mtarld, I wrote that about your alternative proposal, not about mine. So we keep context as an array, add immutable context items and add them with class name index. |
Thank you for this issue. |
Hello? This issue is about to be closed if nobody replies. |
Description
I have an alternative proposal for Serializer context (replaces #43973 for #30818). It requires new contracts for serializer and normalizer, but my approach allows to combine different structured contexts easily without array conversion. Both client and library will work with objects instead of arrays, so offset constants and array processing could be dropped.
Offset constants in the normalizer class, defaults processing, builders
Only ContextItem implementation
Partial, since arrays are not structured
The idea is to have a
Context
class that is a collection of individual context objects, indexed by class. Each context piece must provide adefault
factory method that is called in case the context item was not explicitly passed. Individual context items cannot be mutated or replaced once they are instantiated within a serializer/normalizer call to match the current array behavior, only a newContext
instance can be created via constructor or awith
method. The rest is easier to explain with the code:NewNormalizerInterface
is not a name proposal :) I called it so for simplicity.BC layer ideas
We can add a new interface that supports both
array
andContext
parameter types, using the union operator, and meanwhile mergeContextAwareNormalizerInterface
to reduce the number of contracts in the future.It works, see https://3v4l.org/YmEbP.
Also a helper method
Context::fromArray()
can be introduced to simplify deprecated array context support.IDE support
PhpStorm supports Context::get() autocompletion.
The text was updated successfully, but these errors were encountered: