Magic Hat writes:
> In any case, I'm having second thought about this entire "validation"
> thing... First of, I never really used it in EOF. Except, some time, the
> generic method for checking dumb things like string length or such. Which
> doesn't really belong to an EO though. In any case, why bother with an
> external validation mechanism? Why not simply use old fashioned setter
> methods? If the setter does not like a given value, simply correct the
> problem and/or throw an Exception there. No real need for externalizing
> validation. Plus, separating validation from setting the value introduce a
> potential dichtonomy: it does rely on the "good will" of a third party to
> do the right thing (eg call validate and then set).
I was thinking more about the "dumb" form of EOValidation (string length and
nulls), since I don't use NSValidation either.
But I am still for externalizing it, since setters are unaware of the
context in which they are called. For instance a setter may be tied to the
GUI, and user may perform a few corrections before the changes are
committed.
So it is really up to the setter caller to decide when the validation is
needed.
Andrus
This archive was generated by hypermail 2.0.0 : Tue Sep 03 2002 - 17:47:24 EDT