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

Outermost class never uses a default caster #73

Open
axlon opened this issue Jul 12, 2024 · 1 comment
Open

Outermost class never uses a default caster #73

axlon opened this issue Jul 12, 2024 · 1 comment

Comments

@axlon
Copy link
Contributor

axlon commented Jul 12, 2024

What's wrong

When hydrating a payload back to an object, the hydrator never checks if a default caster exists for the outer most object. Typically this isn't a problem, because most of the time the class you are hydrating consists of properties that the mapper can hydrate (either through casters or just by using reflection). However this also means that you can't use a caster to call another caster (by calling $hydrator->hydrateObject(Some::Class, $somePayload)).

My use case

My current use case for calling one caster from another is that I'm trying to support array shapes, this involves providing an attribute for each key in the array that needs to be cast to a type (e.g. #[CastArrayItem('foo', Foo::class)]), as well as using this package's #[SerializeArrayItems]. For the most part this works fine, but I'm currently unable to hydrate any values that require a caster.

PS. Am happy to attempt a PR if you feel this is the right direction

@axlon
Copy link
Contributor Author

axlon commented Jul 16, 2024

Some observations:

  • ObjectMapperUsingReflection does have this behavior, but its only one way; it checks if the root object can be serialized using a default serializer before doing anything else. It doesn't do this when hydrating.
  • The object mapper created by ObjectMapperCodeGenerator behaves in a similar fashion; it creates a code path that uses a class' default serializer to construct it, but it won't create a code path for hydrating using a default caster unless the class is also a property to another class. Even if it does create a code path for the caster it still won't use it when the class is hydrated directly.

TL;DR: hydration and serialization are not entirely symmetrical, but both implementations are consistent with each other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant