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"?