ObjectHydrator icon indicating copy to clipboard operation
ObjectHydrator copied to clipboard

Outermost class never uses a default caster

Open axlon opened this issue 1 year ago • 1 comments

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 avatar Jul 12 '24 12:07 axlon

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.

axlon avatar Jul 16 '24 11:07 axlon