[EMAIL PROTECTED] wrote:
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; infect($a); a.meth();
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.
Miro
