For "zip code" do you mean US zipcodes? UK postcodes? Any of them? All of them?

I think if there is a "standard zipcode" definition within your company/project/application, then those for attributes are related, and it would make sense to create an separate class for dealing with them. But I would assume such a class to have considerably more functionality that just validation.

If the only constraint on those disparate fields is that they must be positive integers (what size?), then you can probably get away with making them a type.

However, if we are talking about 4 truely disparate and unrelated attributes of 4 truely unrelated classes, that just happen to require a similar type of validation--at the moment--then it would be downright dangerous to use a common routine for performing that vaidation. As soon as one of them changes, the nature of their unrelatedness is likely to cause the the maintenance programmer to modify the validation routine commesurate with the one that changed and be completely oblivious to the other three which haven't.

Finally, if there are sound reasons for using a single vaidation routine for the 4 disparate attributes, I would just call that routine within the second code block of the LVALUE keyword I described. It in no way precludes that.

You can get away with a type for the positive integers even if their ranges differ: it's a parametrizable type.

the nature of their unrelatedness is likely to cause the the maintenance programmer to modify the validation routine

That's just silly and backwards; the kind of tunnel vision resulting from your insistence on validating inside the accessor. If I want to store strings in a property formerly declared as an integer, I'll change the type declaration for the property, not the definition of an integer.

Makeshifts last the longest.

You appear to be suffering from tunnel vision that all valadation is based on data type. Validation based on data type is fine, and when I want that I'll likely have an object that encapsulates more than just validation and so my classes that use that type won't need to do validation so providing a hook for the containing object isn't particularly attractive to me.

The point of validation in an object's "set" method is to validate the request against the state of the object and even cause the setting to impact the state of the object outside of just that particular member variable.

- tye        

That's just silly and backwards; the kind of tunnel vision resulting from your insistence on validating inside the accessor.

Ad hominim but, in my opinion, that is the correct place for it. The first place I am going to look for it, and the right place to code it. You may disagree with that opinion, but denigrating me for holding it does nothing to further yours.

If I want to store strings in a property formerly declared as an integer, I'll change the type declaration for the property, not the definition of an integer.

Which is fine and dandy for those types of validation that lend themselves to being entirely performed as a side effect of a type definition.

But what of all those that do not?

How are you going to define a type for reals in the range 0.0 to 1.0?

And another for those in the range -1.0 to +1.0?

And another for integers that can be (-1|0|+1)?

And another for dates this year? This month? This century?

And another for daytimes? Nighttimes? Weekends? First days of the month?

And one for 3-char strings? and 4-chars strings? and 5-char strings? And lowercase 3-char strings? and uppercase 3-char strings? And lowercase, 3-char strings that begin with 'a'? And lowercase 3-char strings that begin with 'b'? ...or 'c'? ...or 'd'? ....

And every other conceivable form of validation scattered throughout every module on CPAN.

Like I said, using type definitions to perform value validation is a slippery slope that should be avoided at all costs.

All those validations, and vast numbers of others can be performed with a simple regex. One of Perl's most useful, envied and copied features.

Relinguishing that power and ease of use in favour of a gazillion type definitions, or tie classes--replacing a single inline line with many, out-of-band lines--is "silly", and dangerous and ... you know it.

And I am the one exhibiting "tunnel vision"?

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.