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.

Indeed, I have tunnel vision here. After all, I was trying to show BrowserUk that type based validation is useful for cases where I want to validate the type of a value… while his vehemently argued position is that type based validation is a nightmare/useless/something like that.

In any case, thank you for a break in that circle. Yes, of course, state based validation is a different beast.

Makeshifts last the longest.

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

I think a better (but still simplistic) example is a data type for "day of month". How do you write a validator for that unless it also has access to "month of year" and "year" (just in case we are talking about February)? So why make getting access to those other items difficult?

How do I allow $price->Currency = 'yen'; to know that $price->Amount needs to change as a result?

Now blow that up to cases that aren't so simplistic.

- tye        

I don't know why the “parametrizable” never registered regardless of my repeated mention.

1. How are you going to define a type for reals in the range 0.0 to 1.0?
2. And another for those in the range -1.0 to +1.0?
3. And another for integers that can be (-1|0|+1)?
4. And another for dates this year? This month? This century?
5. And another for daytimes? Nighttimes? Weekends? First days of the month?
6. 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'?

1. my $foo is Real( 0.0, 1.0 );
2. my $foo is Real( -1.0, 1.0 );
3. my $foo is InSet( -1, 0, -1 );
4. my $foo is DateTime( year => DateTime.now.truncate( to => 'year' ) ); # ...
5. my $foo is DateTime( hour => [ 8 .. 22 ] ); # ...
6. my $foo is String( len => 3 ); # ...
   my $foo is String( match => /\A a [[:lower:]]{2} \z/ ); # ...

For the Real constructor I could even imagine some syntax like qw( ] 0.0 - 1.0 ] ) (I don't remember which dingbats we'll use in Perl6 for qw//) which would define a range from 0.0 exclusive to 1.0 inclusive — just like the mathematical notation.

Use your imagination. Did I mention declarative programming is bliss for maintainers?

Makeshifts last the longest.

Okay, now extend those to allow any integer if

$self->anotherAttrib == 3;
[download]

With the validation inline, it has complete access to everything that the sub has access to.

And 90% of all those specialist traits are just single lines of Perl blown up into complicated layers of abstraction, that will never be reused, and serve only to add complexity, where none is warrented.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.