Rename Attributes to something else

[henriquemoody]

Considering the work I will be doing on #1799, I think Attributes might not be a good name for it anymore.

Considering options, I think ObjectStructure might be better, although I'm not very sure about it, if I'm really honest.

We could also keep Attributes as is, deprecate it, and then create ObjectStructure with the full support to @var doc blocks.

PS.: To be really honest, I was never a fan of Attributes() anyways, as it's validating the object and the attributes is just the means it does that right now.

[alganet]

v::discover maybe, or v::auto.

Regarding the draft, I'm wondering how you're going to manage possible conflicts (doc says one thing, php says another).

Also a little worried about cache. In-memory only goes so far, and if one needs proper cache compiled on disk would be ideal. It's a complication. If we make just one validator that does both, user has no choice but to use the inneficient in-memory that scans once per php process even if he just wants attributes and has no phpdocs.

[henriquemoody]

I agree that in-memory won't be enough. But, I think it could be the default mode unless the user wants to optimize and use a better caching mechanism. That's why I'm using psr/simple-cache in that implementation, it will give users the choice to improve the performance of parsing docblocks. We can do a step further and cache all validator attributes the by property (although it gets a bit more complicated).

As for giving the user the choice, I'm thinking of that as well, and decoponsing the parsing, not sure if that would be enough. Also, we could keep Arguments as is, and create a new one that's more robust.

My plan of dealing with conflicts is to run all validators (from both attributes and doc blocks) and let whatever doesn't pass fail.

[alganet]

My plan of dealing with conflicts is to run all validators (from both attributes and doc blocks) and let whatever doesn't pass fail.

Fair enough.

As for giving the user the choice, I'm thinking of that as well, and decoponsing the parsing, not sure if that would be enough. Also, we could keep Arguments as is, and create a new one that's more robust.

Maybe:

• v::attributes() - As it is today. Basic property types and attributes.
• v::discovered() - Whatever v::attributes() does + docblocks.

For v::discovered(), I would not offer a default cache and instead force the user to setup a container with his/her preferred psr/cache implementation. It makes it clear that this is not our business to deal with. We can offer documentation on why a persistent cache is the right call and why we cannot readily offer it.

---

One thing that is mostly a feeling is that php docblocks were never first-class citizens. That's why it feels so odd to support them. Most libraries that do are require-dev, not require (phpstan, phpDocumentor, etc).

A path we could take for this, is offer a require-dev solution that generates composite validators from docblock information. v::discovered() then would read from that generated pool and defer to a custom validator auto-generated during development (FluentGen could take on that role eventually, it's already require-dev). No cache needed, no runtime overload, etc. But a generation step would be necessary (nothing is free in this world!).

[henriquemoody]

After decomposing the implementation of Attributes in #1799, I came to believe that we should not have two different validators, but instead allow users to define how they want Attributes to behave via the DIC. Because we need to avoid circular references, and if we have two validators it will be tricky to avoid that, since they're two distinct objects.

We could (maybe) delegate the resolution of all validators to resolver that can be used as dependency for both validators, but if the user decides to use two different resolvers on each object, we'd be in trouble again.

[alganet]

define how they want Attributes to behave via the DIC

Makes sense. What would be the default shipped behavior in your opinion? Choosing that would allow us to ship the most common scenario first.