perl.org wrote: > On Wed, 14 Jul 2004 13:26:36 -0400, Bob Showalter wrote > > > > I second the "huh?" > > > > How did prototyping relate to the trouble with $^T? > > > > How do you define "support prototyping properly?" > > Basically because of my implementation of named parameters. I was > passing -value instead of -seed and the sub was expecting -seed. If > I had been using named parameters instead of hash keys this would not > have been possible.
You might look at the CPAN module Params::Validate for this kind of thing. > > By prototyping I really mean named and typed parameters and a typed > return value (like C). OK. "Prototyping" in perl has a specific (and different) meaning. It's documented in perlsub. Basically, it's used so you can write subs that act more like some of the built-in subs. Consider push(): push(@array, 'foo', 'bar'); Without prototypes, you can't really write your own version of push(), because the contents of @array get flattened along with the remaining args into a single @_ list. Your own version would need to be called more like: my_push([EMAIL PROTECTED], 'foo', 'bar'); With perl's prototypes, you can tell the compiler to require an array name, and yet pass a reference to that array as the actual parameter. It really has nothing to do with named formal arguments or type checking in the C-style prototypes sense. > > I mistyped on my last post - I have seen suggestions that prototypes > should not even be used. Is there a difinitive answer on this? I would agree with this. Prototypes are never needed AFAIK, and I have never used them in any of the code I've written. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
