`PDO::FETCH_CONSTRUCTOR` fetch mode proposal

On Fri, Jan 19, 2024, at 9:47 AM, Lynn wrote:

*snip*

Hi, maintainer of Crell/Serde here, as requested. :-) I am highly skeptical that any serious standardization could happen in core directly. Not because of incompatibility between existing libraries really (we can adapt), but because the problem space is a lot more complex than it first seems, and that complexity means there's many valid but incompatible ways to go about it. Just to use the name example, for Serde, I support a `serializedName` declaration on a given property, but also a `renameWith` declaration that specifies different rules for processing the name. There's built-in options like Prefix('some_string_'), case folding via enum objects (like Cases::snake_case), and you can put an arbitrary object on it as long as it's all compile-time defined. (Eg, you can do a suffix one if you want, but I don't provide it.) The `renameWith` directive can also be put on the class level, and that will apply to all properties unless otherwise specified. Then I'm in the process of adding renaming capability that's tied to when flattening nested objects. And that's just for naming things. How much of that should be standardized? How much should PHP do itself, and how much is better left for either de-facto standardization or FIG? If we do just a little bit (such as a strict `#[SerializedName('some_string')]` attribute and nothing else), does that make it more difficult to do more complex things like I do? Something like `#[SerializedName]` is probably safe enough to do that it wouldn't cause problems, but then what does it actually do *in core* rather than just be a common name for Serde, Symfony, etc. to use? Does serialize() use it? What then happens on unserialize()? How does that interact with __serialize()/__unserialize()? And that's *just* naming things. That's before we even get into type mapping, flattening, defaults, post-deserialize validation, and all the other stuff. So it's possible we could do something here, but it will require a lot of thought and care to not paint ourselves into a corner. Regarding PDO hydration in particular, while a `#[SerializedName]` attribute or similar seems nice, that immediately runs into a problem. What if you want to use that object for populating from a DB, as well as for round-tripping from JSON? Are you locked into the same name in both cases? If not, how do you differentiate them? I have a solution for that in Serde, Symfony Serializer has something similar, but is that something that we want to bake into core? If not, does that mean we cannot support multi-format serializing rules in the future? Additionally, while we're talking mostly about names here, there's also the question of types. Postgres, for instance, supports a much wider set of column types than PDO. For instance, it supports typed array columns (array of ints, array of strings, etc.). PDO sees those as strings, which you need to then parse back out into something, and that parsing is not trivial, because reasons. So if doing a FETCH_CONSTRUCTOR approach, would you need to accept a string in the constructor, then parse it to an array in the body? That precludes using CPP. That's before we even get to custom types, which are sort of like object properties and would probably map to that. But... Is that reasonable to built in by default? How, exactly? All of which is to say that while I would love to make PDO better and the serialization/deserialization story better, I think it's too complex to be really *solved* in core. If anything, we should focus on asking what would make it easier to build user-space wrappers *on* PDO that do that more complex stuff (renaming, type translation, etc.) in user-space. I'm not convinced that FETCH_CONSTRUCTOR would be a net improvement or if it would get in the way of that more complex stuff. I could still be convinced of it, though, if we can be reasonably confident that it doesn't have unintended negative consequences to future design, the way readonly did. --Larry Garfield