Er, isn't that not just the wrong way around? The point is to do the
bookkeeping that an object is needed that does .meth() and that it
is stored in $a, and to complain when that is not the case when it
should be. The earlier the better.

I don't understand why writing 'my X $a' needs at least a declaration
of X, but then '$a.meth()' does not consider '.meth' as a bare method
that needs a declaration in X?

Because you can do

sub infect(X $a is rw)
   role bla {
      method meth() {...}
   $a does bla;

my X $a;

Remember, you can even change the class of instanced objects using 'does' (or 'but', but it'll at least copy the object). And as the example above shows, this is statically intractable - it can happen in a sub in a different autoloaded module.

Also, what do you want to do if you actually want $a.meth() to throw a catchable exception if $a doesn't implement meth? It's what many OO languages do. In fact, I can't recall a single OO language that isn't derived from C++ that does /not/ just throw a runtime exception on unknown method.


Reply via email to