Determine the type string from an object instance

[dantleech]

Hi!

We are experimenting with using Valinor as a serializer for Symofny Messenger in order to save messages in JSON.

The tricky part is storing the type in the Envelope header. The Symfony Serializer just does $object::class ... but for Valinor our type is Class1<Class2>.

Do you think it feasible to introduce a way to generate the string type for a concrete object?

Cheers!

[romm]

Hi @dantleech, nice to see you're trying to integrate Valinor with Messenger. If you succeed, do you think it would be possible for you to integrate your development in https://github.com/CuyZ/Valinor-Bundle?

Concerning your request, the library is currently not capable of detecting the generics of an object. It would require more runtime processing (which can quickly become heavy when working with heavy iterables/objects), and the API of the library would need a certain amount of work to be able to understand that, take for instance:

/**
 * @template T of object
 */
final class SomeClass
{
    /** @var class-string<T> */
    public string $name;
    
    // …
}

The system should be smart enough to infer T. Now think about iterable<T>: should we loop over all values to actually infer T? What about other cases? It looks really heavy to me.

Any thoughts on this? I'm not against trying to implement it, but this might be quite big.

[dantleech]

If you succeed, do you think it would be possible for you to integrate your development in

it's just prototyping for now, and it looks as easy as implementing the Messenger SerializerInterface - with the caveat that it won't support generic types OOTB.

For the Symfony implementation we added a custom "Denormalizer" and a discrimiinator field to the payload envelope:

/**
 * @template TItem of object
 * /
class SomeWrapper {
    /** @param TItem $someDTO */
    public fucntion __construct(public string $type, public object $someDTO) {}
}

where $type is f.e. product and can be mapped to a DTO in the app with a custom Denormalizer.

On reflection this is a better solution for messaging because it makes it easier for messages to be understood by other applications - and (I haven't checked yet) I assume the same is possible in Valinor.

Will be happy to share / make a PR if we go down the Valinor route finally 🙂

Any thoughts on this?

Yeah it does sound like a potential minefield 😅 - part of me was thinking it could somehow happen in the same pass as the denormalization as it would iterate over everything anyway so it could collect the information passively and perhaps resolve it on demand.

---

As indicated above though, maybe this isn't the missing piece of the puzzle and using a discriminator is a better option.

[romm]

Great, I'll let you take some more time to explore and see how it goes. Please keep me updated here, I might even be interested for real projects.

The discriminator approach seems logical indeed. With a "name <=> PHP type" mapping somewhere, using Valinor would be as easy as calling the mapper with the wanted type. I also like this option, as it properly hides technical implementation details behind an abstract, domain-friendly, name.

part of me was thinking it could somehow happen in the same pass as the denormalization as it would iterate over everything anyway so it could collect the information passively and perhaps resolve it on demand.

I didn't think about this solution, but this could fix the performance issue indeed.

[romm]

Thanks for the suggestion and discussion, but after giving it some thoughts I think it is not worth implementing in the library. I hope the discriminator option was enough for you.

BTW, did it work out for Messenger? Or you had to use another (de)serializer?