Sorry but that's dangerous nonsense.

Using anything else than $ would be misleading hence even $ is redundant.

And even $ will make Class->method() act different to Class::method()

My nethods are always intended to be used as methods ($obj->method(...)) and non-methods are always intended to be used as functions (class::function(...)). Method invocations rely on the first parameter being an object of the required type in order to function properly and to make sense. Yes, an end user can do whatever he/she wants (this is Perl, after all), but it won't work correctly in many cases, since additional methods and properties will likely be accessed in a method. For methods, my understanding is that $obj->method(...) and class::method($obj, ...) (assuming $obj is of type class) are functionally identical. Feel free to correct me if I am wrong.

In almost all cases, my methods and fuctions all have specific parameters that they are expecting (i.e., nothing, two scalars, a scalar followed by an array, a hash, etc.). So how is this dangerous?

I am aware that some Perl functions are flexible to accept multiple types of parameters and I have left off prototypes when I have created such functions, but I generally don't create functions like that. If I want to create such functions, then I usually use a hash/hashref as the last parameter and pull key/value pairs as needed.

It's just confusing. It's like using warn for documentation because STDERR is closed in all my scripts, anyway:

close STDERR;
warn "Now we have a better POD to play with!";
[download]

لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

> So how is this dangerous?

a $ prototype forces scalar context

  DB<108> sub nopro  { print @_ }

  DB<109> sub pro ($) { print @_ }

  DB<110> @a=3..7
 => (3 .. 7)

  DB<111> nopro(@a)
34567
  DB<112> pro(@a)
5
[download]

This is especially dangerous if your argument is another function call.

Giving a method a prototype other than ($;@) is at best misleading and will result in awfully ugly bugs if someone is assuming:

> $obj->method(...) and class::method($obj,...) (assuming $obj is of type class) are functionally identical

  DB<113> sub meth ($$) { print @_ }

  DB<114> main->meth(@a)
main34567
  DB<115> main::meth('main',@a)
main5
[download]

if you want a good self documentation, expand arguments to meaningful names:

sub meth {
  my ($self, $x_ax, $y_ax, $arr_ref, @opt) = @_;
}
[download]

I'm not sure what your understanding of "type" is in Perl's context.

Cheers Rolf

PS: Je suis Charlie!

To elaborate on LanX’s comments:

Before using Perl prototypes you should study Tom Christiansen’s essay, “Far More than Everything You’ve Ever Wanted to Know about Prototypes in Perl, ” which is available within the Monastery here. To quote from the opening:

Nearly any programmer you encounter will, when asked what function prototypes are for, report the standard text-book answer that function prototypes are mainly used to catch usage errors at compile time in functions called with an unexpected type or number of parameters. This is what programmers are expecting of prototypes, and what Perl does not give them.

Think coercion rather than checking, and you’ll be closer to the mark. Read the article, then use prototypes only for those specialised cases where they’re really useful.

Hope that helps,