[Validator] Deprecate Constraint::$errorNames in favor of Constraint::ERROR_NAMES
#45371
Conversation
nicolas-grekas
force-pushed
the
no-error-names-prop
branch
from
991ca16 to
67e15bf
Compare
|
I can't help myself, but I always find it weird to override a constant. Designing an API around that feels even weirder. An alternative approach could be to move constraints towards overriding |
|
@derrabus mmmm :) This API is just a declarative piece of code, it needs only a constant, not runtime logic. |
nicolas-grekas
force-pushed
the
no-error-names-prop
branch
from
67e15bf to
ede79ca
Compare
There was a problem hiding this comment.
Could we add a runtime deprecation on Constraint::getErrorName() if the error code is found in the deprecated property but not in the new constant to help understand the vague deprecation "The "Symfony\Component\Validator\Constraint::$errorNames" property is considered final. You should not override it in XX that will be triggered on every custom constraint overriding the property?
carsonbot
changed the title
Constraint::$errorNames in favor of Constraint::ERROR_NAMESConstraint::$errorNames in favor of Constraint::ERROR_NAMES
carsonbot
changed the title
Constraint::$errorNames in favor of Constraint::ERROR_NAMESConstraint::$errorNames in favor of Constraint::ERROR_NAMES
|
do we understand the purpose of https://symfony.com/doc/current/validation/custom_constraint.html#creating-the-constraint-class |
See #12021 |
i don't think getErrorName is that useful :) from the constraint violation POV your have the code+message |
|
@ro0NL that discussion is unrelated to the PR. We have to keep things working. Please open an issue if you want to have a discussion about this method. |
|
i think 1 migration path is enough for a while :) thus either deal with "deprecated prop", or deal with "deprecated method" |
|
This PR is motivated by #45360: deprecating the properties is required for it. Deprecating the method is not motivated by any actual data. We actually have data that supports the method: someone contributed it. So clearly this shows the path to me. |
nicolas-grekas
force-pushed
the
no-error-names-prop
branch
from
ede79ca to
5d5d79e
Compare
good idea, updated. |
…nt::ERROR_NAMES`
nicolas-grekas
force-pushed
the
no-error-names-prop
branch
from
5d5d79e to
aed0b99
Compare
See symfony/symfony#45371 BC Layer kept.
See symfony/symfony#45371 BC Layer kept.
See symfony/symfony#45371 BC Layer kept.
On the road to #43600
The BC layer is a bit light, but since this property seems like a piece of declarative statement that should we accessed only through
Contraint::getErrorName(), I suggest doing it this way, and improve only if/when we get feedback from userland about it.