On 8/17/05, Dave Rolsky <[EMAIL PROTECTED]> wrote:
> I'm going to go over the various features in P::V and see if there are
> equivalents in Perl6, and bring up any questions I have. I think this
> will be interesting for folks still new to P6 (like myself) and existing
> P::V users (I think there's a fair number, but maybe I flatter myself ;)
Thanks!
> P::V also allows one to specify a class membership ("isa)" or one or more
> methods ("can") a given object/class must have. In Perl6 we can just
> specify a class:
>
> sub transmit (Receiver $receiver)
>
> If I understand this correctly, Receiver is a role here, and one that many
> different classes may use/implement. This basically combines the isa &
> can concepts. Instead of specifying required _methods_, we specify the
> role, which seems conceptually cleaner anyway.
... Sometimes. We are missing the "can" functionality (except from
where clauses). That is, how do you specify that you want an object
that does a particular role, but doesn't know it yet. I'm thinking
something like:
role Mortal is automatic {
method die () {...}
}
That is, anything that can "die" is Mortal, even though it didn't say
that it was. Then what really gets tricky is this:
role Mortal is automatic {
method die () {...}
method jump_off_building() { die }
}
class Human {
method die () { die "Auuugh" }
}
Human.new.jump_off_building; # no method found or "Auuugh"?
Anyway, that's beside the point. Moving on.
> Dependencies, Exclusions, and "Require one-of"
>
> With P::V I can do this:
>
> { credit_card_number =>
> { optional => 1,
> depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
>
> credit_card_expiration => { optional => 1 },
>
> credit_card_holder_name => { optional => 1 },
> }
>
> I have no idea how I might do this in Perl6, but I would love to see it
> supported as part of parameter declarations
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration &&
defined $credit_card_holder_name }
{...}
But that's really yucky.
> Similarly, something I've wanted to add to P::V is exclusions:
>
> { credit_card_number =>
> { optional => 1,
> excludes => [ 'ach_bank_account_number' ] },
> }
>
> Another thing that would be really nice would be to require one of a set
> of parameters, or one set out of multiple sets, so we could say "we need
> credit card info _or_ bank account info".
Yeah, I suppose that would be nice. However, when you're doing these
kinds of complex dependencies, you'd like to provide your own error
messages when they fail. That is, instead of:
'$credit_card_number excludes $ach_bank_account_number'
You could say:
'You can't give a credit card number and a bank account number, silly!'
So I wonder whether this kind of logic is better for a P::V module in
Perl 6. Let somebody else think about the hard stuff like that.
> Transformations
>
> Another potential future feature for P::V is the ability to specify some
> sort of transformation callback for a parameter. This is handy if you
> want to be flexible in what inputs you take, but not explicitly write code
> for all cases:
>
> { color => { regex => qr/^(?:green|blue|red)$/i,
> transform => sub { lc $_[0] } }
> }
>
> I suspect that this could be implemented by a user-provide trait like "is
> transformed":
>
> sub print_error ($color where m:i/^ [green | blue | red] $/ is transformed
> { lc })
>
> Presumably this can be done with the existing language. It doesn't add
> anything at compile time, so it really doesn't need to be part of the
> language.
Even things that do add things at compile time don't need to be part
of the language. That's why "use" is a macro. :-)
Luke
