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