The only other thing I can think of to clean this up, is to create a separate class like so

class AssociationOptions
{
    public function __construct(
        private ?bool   $_cascadeCallbacks = null,
        private ?string $_className = null,
        private ?array  $_conditions = null,
        private ?bool   $_dependent = null,
        private ?string $_finder = null,
        private ?string $_bindingKey = null,
        private ?string $_foreignKey = null,
        private ?string $_joinType = null,
        private ?object $_tableLocator = null,
        private ?object $_targetTable = null,
    ) {}
}

but this needs to be done for each adjusted class since the options are different - so not sure if this is actually cleaner.

But in general I am definitely in favour of removing these kind of dynamic property assignments since its easier to find stuff.

The only other thing I can think of to clean this up, is to create a separate class like so

Or we can kill this options argument and make people use the dedicated methods already available for them 😁

Or we can kill this options argument and make people use the dedicated methods already available for them 😁

Oh yes, that would great. But it would require some rector/upgrade tool automation to make that upgrade it easier.

Oh yes, that would great. But it would require some rector/upgrade tool automation to make that upgrade it easier.

We could introduce the new call style in 5.x via changes in bake, docs, and with rector rules. Deprecations could be emit when an options array is used as well.

This seems like something we could safely do in 5.x, or am I missing something?

Yes, it could be done in a new minor with deprecations and updating of baked code.

This looks ok as-is for cleanup.