Does it *need* to be a DTO?

[morrislaptop]

Could this library just work by examining the public properties of a class using reflection?

[aidan-casey]

Good question! Theoretically, we could use the same approach we are with DTOs on other classes. I think the main reason we targeted DTOs specifically was because there was a need for them to be mocked on occasion and they are easy to support. By opening ourselves up to other classes there are a lot of variables that need to be accounted for (e.g. if the class passed has a constructor dependency, how do we handle that?).

I am not opposed to pursuing that if the interest is there. We would need to give a little thought into what that looks like though.

Is this something you would find useful?

[morrislaptop]

Ah true, I've been doing symfony/serializer stuff lately and the amount of different cases they have to handle is scary!

This is sort of what I was looking for but is quite outdated now - https://github.com/stephanecoinon/object-factory

[aidan-casey]

There is certainly potential for a Laravel-like factory package to assist in mocking objects in general (not just models). I would have to think about whether that would be useful to most people, since usually factories are pretty customized to what they are generating.

If we were to implement that, it would be in a different package though. Our main interest here is creating populated DTOs so we can test actions on them instead of spending time generating the correct types for each property. 🙂

[morrislaptop]

@aidan-casey I forked a lot of the code from this package to adapt it for POPOs.

https://github.com/morrislaptop/popo-factory

It would be great to see if it could work together somehow?

[aidan-casey]

@morrislaptop - Moving this to discussions so we can keep this conversation open and also keep the issue board clean. 🙂

Looks great! Do you have a specific proposal in mind? I could definitely see this being valuable, especially with PHP 8 allowing us to manage DTOs from regular classes a little easier.

The main differences that would be found between Spatie's DTOs and POPOs are the entry validation logic, instantiation, and iterable logic. For that reason, I am curious as to whether it might be better to abstract the underlying code that would be used in both to another package and allow these to grow as two separate packages that depend on that.

Curious to hear what you are thinking though!

[morrislaptop]

@aidan-casey I think one package that handled both would be ideal, but a technical challenge to handle all the differences. I think the main differentiation is the instantiation. This is something the Symfony/Serializer can handle by adding a normalizer which would handle DTO specific objects.

https://symfony.com/doc/current/serializer/custom_normalizer.html

I have made a couple of changes in my fork - removing all collection specific code as I wouldn't need to handle that. I also added the concept of the class based object factories (taken from Laravel) which I feel could be useful in this package - https://symfony.com/doc/current/serializer/custom_normalizer.html

[aidan-casey]

@morrislaptop - I agree. Good thought to use the serializer.

I think this could probably be easily achieved if we just strip the DTO specific things and in similar fashion to the current ProperyFactory class, add support for a registerNormalizer() method on the factory and create the serializer on the fly when generating the class. Out of the box it could have a provider for POPOs and a provider for Spatie DTOs that are automatically added on factory bootup.

[morrislaptop]

Would you be interested in doing this within this package (and possibly rename the package) or keep our separate packages?