I’ve noticed that most of the get and set functions for working with validators are to be removed in version 3 of laminas-validator. I’m curious how I would work with validators in the case where I need to modify it? What was the thought process in removing these setters and getters? I have no idea how to migrate existing code that modifies settings on the validators and does not create them. These are part of a validation chain on existing forms. Thanks
e.g.
/**
* Gets the Validator for validating each value
*
* @deprecated Since 2.60.0 all option setters and getters are deprecated for removal in 3.0
*
* @return ValidatorInterface|null
*/
If I remember correctly all validators will be modeled as immutable and will only accept constructor arguments via the options array. You can see this document in prep for migration.
welcome to the forums. As @Tyrsson already said the validator classes are designed as immutable in the next major release. Some years ago the step to make validators stateless was a great decission (The value to be validated must be passed to the isValid() method instead of being set when the validator is initialized). Immutability is the next logical step.
Personally, I would even go one step further and design the options for a validator as a value object with fixed properties that can or must be used.
Anyway … can you name a practical use case in which it is necessary to modify the properties of a validator after initialization? Maybe we can show you a more practical, logical way to use validators in the future (and actually already now).
This cannot be changed so easily, even if this is desired. Because the laminas-input-filter is based on the validator and so changes must be implemented step by step. The next major version of laminas-validator will bring more.
