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 ;)


> 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, 
        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.  :-)


Reply via email to