This would solve #15950, right?

This would solve #15950, right?

Yes, it allows you to achieve the effect described there. In fact, I began my PR by looking at your solution from #21053.

I'll start by saying I'm not a fan of inheritance, because it so often causes these kinds of issues, so I'd usually look for a way of solving this in a different way. That said, I appreciate some codebases might not be able to avoid it.

So my opinions:

1. I feel a bit uncomfortable with it being an "assertion" when it's not itself asserting anything, but only changing other assertions.
2. Can you override or disable assertions on private properties? I don't know how this behaves at present, so perhaps it's a non-issue.

I feel a bit uncomfortable with it being an "assertion" when it's not itself asserting anything, but only changing other assertions.

There are a few of that type already, e.g. AtLeastOneOf, EnableAutoMapping.

Can you override or disable assertions on private properties? I don't know how this behaves at present, so perhaps it's a non-issue.

Yes. Currently - apart from my PR - constraints are merged even for private properties.

Good point that this is already a pattern used elsewhere. EnableAutoMapping definitely feels like configuration and not a constraint.

For me personally, it would help if I could understand how properties and constraints behave with inheritance. Could I help with that, or have you already got something you could share?

For me personally, it would help if I could understand how properties and constraints behave with inheritance. Could I help with that, or have you already got something you could share?

The validation process creates metadata classes, that contain information like constraints against which an object and its properties should be validated, TraversalStrategy, etc. PropertyMetadata, which contains metadata regarding object's property, uses ReflectionProperty to get value of the validated property. The refelection's property accessibility is set to true, which allows it to access protected and private properties of the validated object.

@przemyslaw-bogusz can you please update the description and link to the fixed issue? Note that we recommend keeping all rows in the template table.

What about making this an option in the base Constraint class instead? That would also allow for making this decision per constraint.

@przemyslaw-bogusz Do you have time to take feedback into account?

@przemyslaw-bogusz Do you think you will have time to finish this PR in the next few weeks?

I've been thinking about @xabbuh 's suggestion and I can see one problem with this approach.

In the current proposal, if you choose to override constraints, you can either give the child class same set of constraints but with different options or a completely different set of constraints. For example, if the parent class has Length(max="5"), the child class can override it and can have one of the following scenarios (or any other):

1. Length(max="10")
2. NotBlank()
3. no constraints at all

If we make this an option in the Constraint class, the child class will only be able to override given constraint with a constraint of the same kind but with different options (point 1 of the above example) and it will not be able to achieve scenarios described in point 2 and 3 - it will not be able to discard constraints of the parent class.

Please correct me if I'm wrong. Nevertheless, I will gladly amend the PR, if it's the only way for it to be approved.

We've just moved away from master as the main branch to use 5.x instead. Unfortunately, I cannot reopen the PR and change the target branch to 5.x. Can you open a new PR referencing this one to not loose the discussion? Thank you for your understanding and for your help.

What can I do to this PR to merge/finish?

Can we please have this PR merged?
I just now needed in my code to override asserts in a child class.