Let's say, for fun, I have good reasons to serialize an object. When I then have good reasons to unserialize that object, I'm getting dynamic property deprecation warnings. Is this just the way of the world now or is there something I'm missing? I don't "own" the class, so I can't easily mark dynamic properties as allowed before serializing (and I'm not even sure that would work).

@EdGrosvenor *could* you own it?

#[AllowDynamicProperties]
class mine extends theirs { }

(or adding the property)

and then using your copy only?

but also yes iirc only stdClass or those with __get/set is gonna be silent about it.

@bobmagicii maybe. But the warning seems to be talking about numeric properties that don’t exist on the class at all. Might be a side effect of serializing and unserializing. So I’d be adding properties that don’t exist for no really good reason. I’m wondering if I can get a better result using the symfomy serializer and taking a bit more control over what the stored object looks like.
@EdGrosvenor like its trying to write $obj->5 = 'val'; ? that would be pretty illegal. 🤔
@bobmagicii Yes, that seems to be what it's trying to do.
@EdGrosvenor yeah then none of those ideas were good we really got to get that stored as an array in your serialized data so it hydrates correctly. sounds like it got wrote as { 5: 'val' } 😔 which i had thought php worked around at some point.
@bobmagicii Part of me wonders whether it would be easier just to fork the package and give it some love. It's infrequently maintained because it just works, but it's old. If the maintainer likes the paint job, great. If not, it wouldn't be hard to just maintain my own fork because it almost never needs updates these days.

@EdGrosvenor every time im considering this people remind me composer has a feature which it can apply patches to packages after it installs them.

i've never once seen it myself but the legend is well known it seems.