@bschussek I woud much rather see new method than adding magical switches as parameters to existing ones. New method is easier to find and use - It's obvious what it does.
bschussek - 11 years ago
@Hugo: That doesn't really make sense. We can't specify in a type hint, for example, that a class should implement both interfaces.
Hugo Hamon - 11 years ago
For BC I think it's safer to add a new method and deprecate the previous one (to be removed in 3.0). Instead of modifying the current FormInterface, why not adding a new FormErrorInterface so that a Form instance implements both FormInterface and FormErrorInterface? Those two interfaces may be merged in branch 3.0.
Even though we're actually using getErrors, I think that rather than having x methods (getErrorIterator, getErrorAsString, getErrorAsUnicorns, ....) it should be better to have an iterator once and for all.
Leave a Comment
Give others the chance to vote.
Share this poll, because the more votes the better.
@bschussek I woud much rather see new method than adding magical switches as parameters to existing ones. New method is easier to find and use - It's obvious what it does.
@Hugo: That doesn't really make sense. We can't specify in a type hint, for example, that a class should implement both interfaces.
For BC I think it's safer to add a new method and deprecate the previous one (to be removed in 3.0). Instead of modifying the current FormInterface, why not adding a new FormErrorInterface so that a Form instance implements both FormInterface and FormErrorInterface? Those two interfaces may be merged in branch 3.0.
Even though we're actually using getErrors, I think that rather than having x methods (getErrorIterator, getErrorAsString, getErrorAsUnicorns, ....) it should be better to have an iterator once and for all.